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UNIT 1 


INTRODUCTION 
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SNA OVERVIEW 


A THREE DAY SEMINAR ON AN OVERVIEW OF SNA WITH 
A REVIEW OF LIMITATIONS OF PRE-SNA SOLUTIONS AND 
AN OVERVIEW OF ADVANCED COMMUNICATIONS FUNCTION FOR 
VIRTUAL TELECOMMUNICATIONS ACCESS METHOD IACF/VJ AM)., 
ADVANCED COMMUNICATIONS FUNCTION FOR TELECOMMUNICATIONS 
ACCESS METHOD JACF/TCAM)_, AND ADVANCED COMMUNICATIONS 
FUNCTION FOR NETWORK CONTROL PROGRAM <ACF/NCP) 


SEMINAR IS SUITABLE FOR SOME ONE STARTING IN SNA 

AND IS MEANT TO BE USED AS THE FIRST INTRODUCTORY 
COURSE 

NOT SUITABLE FOR PEOPLE WITH PRIOR SNA KNOWLEDGE OR 
EXPERIENCE 

SOME RELEVENT QUESTIONS: 

WHY IS SNA RELEVENT TO OUR PARTICULAR NETWORK? 

WHAT MAKES A NETWORK SNA? BSC IN SNA? 

WHAT DO I NEED TO KNOW ABOUT SNA TO OPERATE IN 
THIS ENVIRONMENT EFFECTIVELY 
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BACKGROUND THAT WILL BE HELPFUL 


1. FAMILIARITY WITH COMPONENTS OF A DATA 

COMMUNICATIONS SYSTEM 

2. AT LEAST CONCEPTUAL FAMILIARITY WITH IBM 

SYSTEM SOFTWARE COMPONENTS SUCH AS 

OPERATING SYSTEM, ACCESS METHODS, AND 
TELEPROCESSING MONITORS 

4. MORE THAN SUPERFICIAL FAMILIARITY WITH 

BTAM, EP, AND TELEPROCESSING MONITORS 

3. GENERAL AWARENESS OF CURRENT TRENDS IN 

IN DATA COMMUNICATIONS TECHNOLOGY 

SQMg_QiSERVAIIQNSi 

1. DIVERSITY OF EXPECTED AUDIENCE; DIFFERENT 
AREAS AND LEVELS OF EXPERTISE 

2. INHERENT PROBLEMS IN PRESENTING INFORMATION 
TO A DIVERSE GROUP SUCH AS ABOVE 
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TP ACCESS METHODS FROM IBM 


BASIC TELECOMMUNICATIONS ACCESS METHOD (BTAM) 


OLDEST (SINCE MID 60s) V“ 
SIMPLEST ' /~'-ry+- ^ 

STILL THE MOST COMMON 


ADVANCED COMMUNICATIONS FUNCTION FOR VIRTUAL 
TELECOMMUNICATIONS ACCESS METHOD (ACF/VTAM) 

LATEST (SINCE MID 70s) 

VERY COMPLEX 

PRIMARY VEHICLE FOR SNA 


ADVANCED COMMUNICATIONS FUNCTION FOR TELECOMMUNICATIONS 
ACCESS METHOD (ACF/TCAM) 

SINCE EARLY 70s 
MOST COMPLEX 

SNA SUPPORT, ALTERNATIVE TO VTAM 
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ACCESS METHODS, FEP SOFTWARE, AND PROTOCOLS 


WHAT GOES WITH WHAT 
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ACF: ADVANCED COMMUNICATION FUNCTION 


1. PART OF SNA CAPABILITIES, STEP IN EVOLUTION. 

2. ANNOUNCED 1977, MOST SIGNIFICANT NEW FEATURE: MULTIPLE 
HOSTS ON A COMMON NETWORK. 

3. ALL PRODUCT RELEASES (VTAM, TCAM. AND NCP) WITH THESE NEW 
CAPABILITIES HAD THE "ACF" PREFIXES WITH THEIR NAMES. 

/ 

4. TODAY ALL CURRENT RELEASES ARE "ACF" RELEASES AND HAVE BEEN 
FOR A FEW YEARS. So THE ACF DESIGNATION HAS, IN A SENSE, 
BECOME MEANINGLESS. 

5. ALL REFERENCES TO VTAM. TCAM. AND NCP IN THIS LECTURE ARE TO 
THEIR "ACF" RELEASES EVEN THOUGH "ACF" IS NOT SHOWN. 


WHAT'S THE STORY ON "ACF" 
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THE ROAD MAP 


THE STONE AGE: 

- OVERVIEW OF BTAM/EP 

- ASYNCHRONOUS AND BINARY SYNCHRONOUS COMMUNICATIONS 
(BSC) PROTOCOLS 

- TELEPROCESSING MONITORS 

THE RENNAISANCE: 

LIMITATIONS OF PREVAILING IBM TECNOLOGY 
CUSTOMER NEEDS FOR NEW SOLUTIONS 
THE GREAT LEAP FORWARD 

NEW ANSWERS, NETWORKING ARCHITECTURES 
SNA OVERVIEW, SINGLE DOMAIN AND SDLC 
DOING IT VIRTUALLY 

SNA IMPLEMENTATION WITH VTAM AND NCP 
SO WHAT’S AN 'MCP’7 

DOING IT WITH ACF/TCAM 
HOW IS YOUR INTERNODAL AWARENESS? 

- SELECTED TOPICS IN MULTIPLE SYSTEMS NETWORKING 
FACILITY (MSNF) 
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UNI T 2 

HQSI_CQNIRQL_SQFTWARE_REVIEW 

objectives 

TO REVIEW functions/definitions of: 

10 SUBSYSTEM AND RELATIONSHIP TO MULTIPROGRAMMING 
JOB MANAGER AND RESOURCE ALLOCATION (TP LINES) 

10 OPERATION, ACCESS METHODS, AND CHANNEL PROGRAMS 
DESCRIBING LINES TO THE OPERATING SYSTEM, IODEVICE 
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MAIN MEMORY 






\0 


.program A. 


I 



2. WHAT ARE THE IMPLICATIONS FOR THE PROGRAM 
IF THE DATA IS NOT IN MAIN STORAGE? 

3. WHAT IS A COMMON APPROACH TO IMPROVE CPU 
UTILIZATION BECAUSE OF MAIN STORAGE 
LIMITATIONS? 


THE HISTORIC CPU VS. MAIN STORAGE LIMITATIONS DILEMMA 
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TRANSFERRING CONTROL FROM ONE ONE APPLICATION TO ANOTHER 
DURING AN I/O OPERATION 


MAIN STORAGE 


j - 

I -GET RECORD - 



WHILE I/O CHANNEL EXECUTES CHANNEL COMMANDS, 

THE CPU CAN EXECUTE INSTRUCTIONS FROM ANOTHER 
PROGRAM 
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ABILITY TO RUN MORE THAN ONE PROGRAM CONCURRENTLY 
ON THE MACHINE 

AN ATTRIBUTE OF THE OPERATING SYSTEM AND NOJ OF 
THE CPU 

PRIMARY PURPOSE: TO INCREASE CPU UTILIZATION ^ T 
NOT POSSIBLE WITHOUT AN INDEPENDENT I/O CHANNEL 


CAPABLE OF EXECUTING COMMANDS (INSTRUCTIONS) 






OPERATING SYSTEM .COMPONENTS OF INTEREST FOR 

teleprocessing 


APPLICATIONS 

AND 

PACKAGES 




! DATA 

i MANAGEMENT 
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ALLOCATING RESOURCES TO A JOB 












DESCRIBING I Q_RESaURCES TO THE OPERATING SYSTEM 


SUBCHANNELS: 


1 . 


2 . 


EACH 

PATH 


SUBCHANNEL 
THROUGH A 


REPRESENTS A UNIQUE DATA 


CHANNEL 


2 1 


FOR OS PURPOSES EACH 
370X (NCP) IS ASSIGNED 


LINE (EP) OR EACH COMPLETE 
A UNIQUE SUBCHANNEL 


3. FOR EACH SUBCHANNEL, THE PROFILE OF THE DEVICE 
ASSIGNED TO IT IS KEPT IN A TABLE CALLED 

UNIT CONTROL BLOCK <UCB>. CONVERSELY, THERE 
IS ONE_UCB_PER_DEVICE 

4. STANDARD IBM PROVIDED SYSTEM GENERATION PROCEDURES 
ARE USED CREATE UCB TABLES 
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ILLUSTRATIVE MACROS FOR DESCRIBING TP LINES 


TO AN OS TYPE OPERATING SYSTEM IN AN EP/BTAM ENVIRONMENT 


IODEVICE 

ADDRESS=OFF, 

UNIT=3705, 

■ 

• 

NATIVE SUBCHANNEL 

FOR 3705 

IODEVICE 

ADDRESS=OFO, 

UNIT=BSC1 

SUBCH OFO ASSIGNED 
TO A BSC1 LINE 

IODEVICE 

ADDRESS=0F2, 

UNIT=BSC1 

SUBCH 0F2, ONE MORE 
BSC1 LINE 

IODEVICE 

ADDRESS=0F3, 
UNIT=BSC3 

SUBCH 0F3 ASSIGNED 
TO A BSC3 LINE 

IODEVICE 

ADDRESS*(0F8,6), 

UNIT=TWX, 

FEATURE=AUTOANSR 

6 TWX LINES 
SUBCHNLS 0F8-0FD 
HOST TO AUTO-ANSWER 

IODEVICE 

ADDRESS=0F5, 

UNIT=BSC2, 

FEATURE=AUTOCALL 

SUBCH 0F5 ASSIGNED 
FOR BSC2 LINE 

HOST IS TO DIAL OUT 


NOTE: BSCl=POINT TO POINT, PRIVATE 
BSC2-P0INT TO POINT, SWITCHED 
BSC3=MULTIPOINT, PRIVATEr" 0 

(FOR NCP ENVIRONMENT ONE SUBCHANNEL WOULD SUFFICE FOR 
THE WHOLE NETWORK) 
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JQ§_QQNIBQk_LANGyAGE_lJCLi_AND_JOB_MANAGEMENI 

OS OR JOB MANAGER KNOWS THE TOTAL UNIVERSE OF 10 DEVICES 
IN THE SYSTEM VIA UCBs DEFINED DURING SYSTEM 

GENERATION 

EACH PROGRAM, AS IT ENTERS THE SYSTEM FOR EXECUTION, 
MUST DECLARE RESOURCES NEEDED BY IT SO THAT THE 

JOB MANAGER CAN DETERMINE WHETHER RESOURCES NEEDED 
ARE AVAILABLE OR NOT 

JQi_CONIROL_LANGUAGE IS THE MEANS BY WHICH A 
PROGRAMMER INFORMS THE JOB MANAGER AT EXECUTION 
TIME THE RESOURCES NEEDED TO RUN THE PROGRAM 

THREE MAJOR TYPES JCL STATEMENTS USED ARE: 
o JOB SIAIEMENT 

o EXEC STAIEMENI 

o DATA DEFINITION (DD) STATEMENT 
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COMMON JCL STATEMENT TYPES 


JOB STATEMENT 


o 

JOB 

NAME 

o 

JOB 

ACCOUNTING INFORMATION 

o 

STORAGE, PRIORITY, ... 


EXEC_STATEMENT 

o NAME OF PROGRAM TO BE RUN 

o OTHER OPTIONAL INFORMATION 


daia_definition_iddi_siatemeni 

o DECLARES 10 RESOURCES (FILES, NETWORK) 

NEEDED BY THE PROGRAM 

o ONE DD STATEMENT PER FILE AND LINE (EP) 

OR PER 370X (NCP) 

o TELLS THE OPERATING SYSTEM WHETHER THE 

RESOURCE BEING IDENTIFIED IS TO BE 

EXCLUSIVELY OWNED BY THIS JOB OR CAN IT 
BE SHARED WITH OTHER JOBS IN THE SYSTEM 
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TASK MANAGEMENT 


JOB 1 


\ 


< 


JOB 2 


l 

! < 



WAITING FOR AN 
10 TO COMPLETE 


CAN USE THE CPU 
BUT JOB 3 HAS A 
HIGHER PRIORITY 


JOB 3 


<- CURRENTLY USING 

CPU (i.e. ACTIVE) 


0 S 


TASK 

MANAGEMENT 


o WHO USES THE CPU NEXT ? 

o WHERE IS A PROGRAM TO BE RESTARTED 

AFTER COMPLETION OF ITS REQUESTED OPERATION? 
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data management 


A COLLECTIVE NAME FOR ALL ACCESS METHODS AVAILABLE 
WITH AN OPRATING SYSTEM 



I APPLICATION 

I 

I 

J PROGRAM 


I 



access_meihodl 

A DISCIPLINE FOR ORGANIZING, STORING AND 
RETRIEVING INFORMATION FROM 10 DEVICES 
A MAJOR FUNCTION: (W~~PROVIDE INSTRUCTIONS 


FOR THE CHANNEL^ TO AFFECT DATA TRANSFER 
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WHAT MUST A PROGRAM TELL THE ACCESS METHOD 


TO REQUEST DATA TRANSFER 


A 

ACCESS 

p <- 

-> METHOD 

1 P 


L 



CHNL 


> 


10 

RESRCE 


1. WHERE IS THE DATA TO BE MOVED FROM OR 
PLACED AT IN MAIN STORAGE 

2. WHETHER DATA IS TO BE MOVED FROM OR TO 
MAIN STORAGE 

3. HOW MUCH DATA IS TO BE MOVED 

4. DESCRIPTION OF DATA ON THE 10 MEDIUM 
AND WHERE TO PLACE DATA ON 10 DEVICE 
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ELQW_QE_QQNIRQL_during_an_qperation: 

TmAJOR ACTIVITIES) 



NOTES: 


1. 

NOT 

ALL DETAILS SHOWN 

2. 

ccw: 

CHANNEL 

COMMAND 

WORD 

3. 

csw: 

CHANNEL 

STATUS 

WORD 
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I/O operation: flow of control 


1. Application program sends a request -for an 10 to the 
access method. 

2. Access method validates the request and builds a 
channel program. 

3. Channel executes the channel program thereby 
transferring data to/from main storage. 

4 . Channel places the status of the I/O operation at a 
predetermined location called the Channel Status Word, 
CSW, and interrupts the CPU. 

5. Access method analyzes the CSW, may try error recovery 
if appropriate. 

6 . Access method returns control to the application 
program with an indication of whether the 10 completed 
successfully or not. 









UNIT 3 


IBM 3705/EMULATION PROGRAM (EP) 


SSjZICTIVESi 

TO DESCRIBE THE FUNCTION OF MAJOR 3705 HARDWARE 
COMPONENTS 

TO DESCRIBE THE FUNCTION OF MAJOR EP 
GENERATION MACROS 




WHAT IS THE 370X 


o A SPECIALIZED MINICOMPUTER 

PROCESSOR (CENTRAL CONTROL UNIT) 
MEMORY 

NO SECONDARY STORAGE 
NO CONSOLE EXCEPT MODEL 3725 

o VARIOUS MODELS AS DISCUSSED EARLIER 


WHAT IS THE EMULATION PROGRAM: 
o CONTROL SOFTWARE FOR 370X 

o MAKES THE 370X APPEAR LIKE THE OLD, NON-PROGRAMMABLE IBM 
270X 

o PREPARED IN THE HOST AND DOWN-LOADED IN TO THE FRONT END 
BEFORE FEP CAN BE USED 
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FUNCTIONS OF 370X IN EP MODE 


1. MAKES UP FOR THE SPEED MISMATCH BETWEEN 
NETWORK AND THE SYSTEM 370 

2. PROVIDES STANDARD INTERFACE REQUIRED BY 370 

CHANNEL ON BEHALF OF THE NETWORK 

3. PROVIDES PAD AND SYN CHARACTERS FOR BSC AND 
START/STOP BITS FOR ASYNCH LINE PROTOCOLS 

4. EXECUTES CHANNEL COMMANDS ORIGINALLY PROVIDED 
BY THE ACCESS METHOD 

5. COMPUTES AND CHECKS BCC FOR BSC LINES 

6. PROVIDES STATUS INFORMATION TO HOST IN RESPONSE 

TO CERTAIN CONTROL CHARACTERS AND NETWORK 
CONDITIONS 

7. CONTAINS NO TERMINAL IDs AND INITIATES NO ACTION 

WITHOUT HOST COMMANDS 
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3705 HARDWARE COMPONENTS 
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1. BASIC MACHINE: CCU, MAIN STORAGE, CONTROL PANEL 


2. CHANNEL ADAPTER: CONNECTS 3705 TO HOST CHNL, FOUR 

TYPES, 1-4. ONLY 1 AND 4 FOR EP 


3. COMMN. SCANNER: BUFFERS LINE DATA, PROVIDES CLOCKS, 

MANAGES LIBs AND LINE SETS 


4. LINE INTERFACE BASE (LIB): PROVIDES HOUSING FOR MAX 

8 LINE SETS 


5. LINE SETS: PROVIDES MAX 2 HDX PORTS WITH 

ElA INTERFACE FOR EACH PORT 


MUST HAVE AT LEAST ONE OF EACH OF THE ABOVE 
COMPONENTS IN A WORKING 370X 


EP-4 

























CREATING AN EMULATION PROGRAM 


o 3705 DERIVES ALL ITS INTELLIGENCE FROM EP 

WHICH MUST BE CREATED BY THE CUSTOMER 

o GENERATION OF EP REQUIRES CREATING VARIOUS 

TABLES CONTAINING INFORMATION SUCH AS 

GENERAL CHARACTERISTICS OF THE 370X 

AND THE EP ITSELF 

TYPES OF CHNL. ADAPTERS, SCANNERS, 

AND CLOCKS 

CHARACTERISTICS OF EACH LINE ATTACHED 
TO THE 370X 

o IBM PROVIDES CODING AIDS (MACROS) TO EASE THE 

TASK OF CREATING THE ABOVE TABLES 

o SINCE 370X DOES NOT HAVE ENOUGH 'HORSE-POWER' 

ACTUAL CREATION OF THE EP PROGRAM TAKES PLACE 


IN SYS 370 







MACROS AVAILABLE TO DEFINE EP PROFILES 


BUILD 


CSB 


GROUP 


LINE 


GENEND 


ONE AND ONLY ONE BUILD MACRO PER EP 
GENERATION, DESCRIBES THE ** SYSTEM* ITSELF 

DESCRIBES A COMMN. SCANNER, ONE/SCANNER 

DESCRIBES COMMON CHARACTERISTICS OF A GROUP 
OF SIMILAR LINES 

DESCRIBES CHRACTERISTICS OF LINE, ONE/LINE 

INDICATES END OF TABLES, MUST BE THE VERY 
LAST MACRO. 
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AN EXAMPLE OF EP MACRO SEQUENCE 


A 370X WITH 2 SCANNERS, 2 LINES USING ONE 
TYPE OF PROTOCOL AND A THIRD LINE WITH A 
DIFFERENT PROTOCOL 



BUILD 

THE 

'BOX’ ITSELF 



CSB 

1ST 

SCANNER 



CSB 

2ND 

SCANNER 


GRP1 

GROUP 

1ST 

GROUP WITH 2 

LINES 

G1L1 

LINE 

1ST 

LINE IN THIS 

GROUP 

G1L2 

LINE 

2ND 

LINE IN THIS 

GROUP 

GRP2 

GROUP 

BEGIN NEXT GROUP 


G2L1 

LINE 

THE 

ONLY LINE IN 

THIS 


GENEND 

END 

OF GENERATION 

TABLES 


GROUP 
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IE macros: illustrative values 


MACRO NAME VALUE COMMENTS 


V 

V 


V 

BUILD 

TYPGEN-EP, 

TYPE 

OF GENERATION 


TYPSYS-OS, 

TYPE 

OF HOST OP SYS 


MODEL-3705—2, 

• 

m 

TYPE 

2 3705 

CSB 

TYPE-TYPE2, 

TYPE 

OF SCANNER 


GRF'X GROUP LNCTL-BSC, 

DIAL-NO, 


A BSC GROUP 

PRIVATE/DEDICATED LINE 


LINE1 LINE 


SPEED-9600, 
ADDRESS=... 
TERM—3271, 


LINE SPEED IN BPS 
PORT AND SUB CH ADDR 
TYPE OF TERMS ON LINE 


GRPY GROUP LNCTL=SS, 

DIAL=YES, 


AN ASYNCH GROUP 
SWITCHED LINES 


LINE2 LINE 


SPEED-110, 
ADDRESS-.. 
TERM-TWX, 


LINE SPEED IN BPS 
PORT AND SUB CH ADDR 
TWX TYPE TERMS 


GENEND 






705 EP EXERCISE 


SYSTEM 370 


BTAM 

BASED SOFTWARE 


0. S. 


! I/O CHNL 


SCANNER ! 


LINE SET 


C. A. 


-LIB 


BSC3 @4800 BPS SS, AUTOANSWER 03OOBPS 


For the configuration above, code appropriate EP macros in the 
correct order. Where applicable, code those values that were 
discussed in the class. 












3705 MODEL 80 


o DESIGNED AND PRICED FOR ENTRY LEVEL CUSTOMERS 

o FUNCTIONALLY NO DIFFERENT THAN EARLIER MODELS 

o NO DIFFERENCE AS FAR AS SYSGENS AND INTERFACES ARE 

CONCERNED 

o BETTER PRICE OERFORMANCE THAN OLDER MODELS 

SQEIWABi configuraxions: 

EP, NCP, AND PEP 
HARDWARE CONFIGURATIONS: 

THREE SUB-MODELS: 

4 LINES 10 LINES 16 LINES 

19.2 KBPS HIGHEST LINE SPEED FOR BSC AND SDLC, 

9600 BPS FOR S/S 

50 KBPS FOR DIGITAL CIRCUITS 

ONLY TYPE 2 SCANNERS 

TYPE 1 AND 4 CHANNEL ADAPTERS (TYPE 1 ONLY ON BYTE MUX 
CHANNELS) 

CAN OPERATE AS A REMOTE 

TOTAL CAPACITY SENSITIVE TO MESSAGE SIZES AND LINE SPEEDS 
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3725 MODELS 1 AND 2 

o LONG AWAITED AND SPECULATED MACHINES 

o DISAPPOINTING IN TERMS OF WHAT WAS ANTICIPATED 

o BETTER PRICE PERFORMANCE THAN OLDR MODELS BUT NO NEW 
MAJOR FUNCTIONS EXCEPT THE CONSOLE 

o SOME LONG STANDING SHORTCOMINGS: 

NO SECONDARY STORAGE 

NO MESSAGE SWITCHING 

MOST OF THE CONTROL STILL IN HOST (WOULD REMAIN SO 
TILL NEW ACCESS METHODS ARE AVAILABLE) 

STILL NO TRUE "AUTO BAUD RATE DETECT” 

DIAL DIGITS IN HOST 
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3725 MODELS 1 AND 2 (CONTD.) 


BOTH SUPPORT: 

CONSOLE TERMINAL 
EP, NCP, PEP 

ACF/NCP AT LEASET VERSION 2 

MODULO 128 ACKNOWLEDGEMENTS ON NCP-NCP LINKS 

SEPARATE PROCESSOR AND DISKETTE FOR THE OPERATOR SUBSYSTEM 

MICROPROCESSOT BASED SCANNERS 

NEW MODELS DO NOT SUPPORT OLD LIBS, LINE SETS, SCANNERS AND 
CHANNEL ADAPTERS 

NEW HARDWARE HAS NEW NAMES 

MODEL 1: 

MAX 256 LINES 

MAX 2M STORAGE (1M WITH EP) 

UP TO FOUR 3725s CAN SHARE THE SAME CONSOLE WITH A SPECIAL 
OPTION 

MODEL 2: 

MAX 24 LINES 
MAX 512 K 

EXPANSION BOX: 3726 

SYSTEM CONSOLE: 3727 
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UNIT 7 


BASIC TELECOMMUNICATIONS ACCESS METHOD 

» 

(BTAM) 


OBJECTIVES: 

AT THE CONCLUSION OF THIS UNIT, THE ATTENDEE SHOULD BE ABLE TO: 

1. DESCRIBE MAJQR FUNCTIONS PERFORMED BY BTAM 

2. IDENTIFY MAJOR MACROS AND FACILTIES AVAILABLE WITH BTAM 

3. DESCRIBE THE LOGICAL FLOW A BTAM PROGRAM AT A HIGH LEVEL 

4. DESCRIBE HOW POLLING AND SELECTION LISTS ARE CODED FOR IBM 
3270s 
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WHAT BTAM DOES 


READ A MESSAGE 

a 

a 

ANALYZE ERRORS 

a 

PROCESS MESSAGE 

a 

a 

WRITE MESSAGE 

a 

a 

a 

a 

NETWORK DESCRIPTIONS 


BTAM ROUTINES AND CODE 


OPERATING SYSTEM 


A 


BTAM 

BASED 

ONLINE 

SYSTEM 


I 


v 


o PROVIDES MACROS FOR APPLICATION PROGRAM TO: 

SPECIFY I/O (READ/WRITE) REQUESTS 
SPECIFY NETWORK DESCRIPTIONS 

o CREATES CHANNEL PROGRAMS BASED UPON APPLICATION REQUEST 
o INITIATES CERTAIN ERROR RECOVERY PROCEDURES 
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BTAM APPLICATION PROGRAM 
(COMMUNICATIONS FUNCTIONS) 


EXECUTABLE CODE: 

1. ACTIVATE (OPEN) LINES 

2. ISSUE I/O REQUESTS TO RECEIVE AND SEND MESSAGES 

3. SYNCHRONIZE CPU OPERATIONS WITH I/O OPERATIONS 

4. ANALYZE BTAM REPORTED ERROR 


TABLES AND PROFILES: 

1. NETWORK DESCRIPTIONS: 

LINES, TERMINALS, DIAL OUT NUMBERS, ... 

2. INPUT/OUTPUT AREAS TO RECEIVE OR SEND MESSAGES 

3. PARAMETER LIST FOR BTAM AND APPLICATION TO TALK TO EACH 
OTHER 
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WHAI_MlJST_Ygy_l<NgW_^BEFOREl_CODING_A_BTAM_PROGRAM 

1. LINK PROTOCOLS 

2. YOUR DEVICE 

o BSC/SS 

o BUFFER SIZE 

o CONTROL CHARACTERS, COMMANDS, ORDERS 
o DATA FLOW SEQUENCES 

3 . SOURCES OF INFORMATION 

o BTAM REF. MANUAL 

o GENERAL INFO. P. 1-52 

o SPECIFIC DEVICES, SEE TABLE OF CONTENTS 
o DEVICE TECHNICAL REFERENCE PROVIDED 

BY THE VENDOR FOR DEVICES IN YOUR NETWORK 
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MAJOR DTAM MACROS 


EXECUTABLE: 

OPEN 

CLOSE 

READ 

WRITE 

WAIT 


OPENS A GROUP OF LINES AND LOADS BTAM 
CLOSES A GROUP OF LINES AND REMOVES BTAM 
REQUESTS DATA FROM THE NETWORK 
SENDS DATA TO THE NETWORK 

SUSPENDS THE PROGRAM PENDING I/O COMPLETION 


TABLE AND PROFILES: 

DCB DATA CONTROL BLOCK, DESCRIBES A GROUP OF 

SIMILAR LINES 

DFTRMLST DESCRIBES TERMINALS ON A LINE 

DECB PARAMETER LIST FOR APPLICATION AND BTAM TO 

TALK TO EACH OTHER (THIS IS NOT A MACRO) 
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A_BIAM_PROGRAM_LOGIC_FLOW 


BTAMPGM START 

program initialization 
code 


* 

* 


a 

OPEN GROUP1 LOAD BTAM 

a 

a 

READ _,AREA ADDRESS,LENGTH,. 

WAIT 


process message received and 
create an output message 

a 

a 

WRITE .MSG ADDR,MSG LENGTH, 


WAIT 


loop back to READ next 
message, end of day the 
■following logic 


a 

CLOSE GROUP1 CLOSE NETWORK 

BR 14 TERMINATE PGM 

MESSAGE AREAS AND TABLES NEEDED IN THE PROGRAM 
FOLLOW 

GROUP 1 DCB .. DEVD=BS, _ 

POLLST DFTRMLST .C1C140402D. 


decb area 


INAREA DS 


CL?? 


MSGOUT DC 


C ’WRITE ME TO CRT’ 


END 


BTAM-6 









DESCRIBING NETWORK IN A BTAM PROGRAM 


o PRIMARY TABLES 

DATA CONTROL BLOCK (DCB) 

TERMINAL LIST DEFININITIONS (DFTRMLST) 

o INFORMATION CODED 

LINES: PRIVATE / SWITCHED 

BSC / SS 

FOR PRIVATE LINES: POLLING SEQUENCES 

SELECTION SEQUENCES 
FOR SWITCHED LINES: HOST ID 

DEVICE ID 
DIAL DIGITS 
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DATA CONTROL BLOCK (DCB) MACRO 


(name) DCB DSORG^CX,DDNAME- 


1. DCB DESCRIBES A GROUP OF SIMILAR LINES 

2. DSORG-CX INDICATES A GROUP TP LINES 
SUPPORTED VIA BTAM 

3. DDNAME= IDENTIFIES THE NAME OF THE JCL 

STATEMENTS THAT IDENTIFY PHYSICAL LINES 

REPRESENTED BY THIS DCB 


DD 
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BiLAIIONSHIP_BEIWEEN_yCB A _pCB A _AND_JCL 

1. OS SYSTEM PROGRAMMER DEFINES UCBs DURING 


OS SYSGEN TO 
SUBCHANNELS 

ASSIGN 

LINES TO 

SPECIFIC 


UCB 

UCB 

UCB 

UCB 

UCB 

UCB 

• 

: oio i 

: on 

S 012 

S 013 

! 014 

• 

: ois : 


I I 

I I 


2. APPLICATION PROGRAMMER DESCRIBES GENERAL 

CHARACTERISTICS OF THE LINES VIA A DCB AND 
THE DCB IDENTIFIES THE JCL VIA 'DDNAME’ 

BSCDCB DCB __DDNAME-BSLINES,_ 


3. AT PROGRAM EXECUTION TIME PROGRAMMER MUST ENSURE 
THAT JCL CONTAINS A SET OF DD STATEMENTS THAT 
BEGIN WITH THE NAME BSLINES (IN OUR EXAMPLE) AND 
THAT THESE STATEMENTS IDENTIFY THE CORRECT UCBs 


//ONLINE 

// 


JOB (PAYROLL),.,RE6I0N=. 

EXEC PGM=PAYRL123 


//BSLINES 

DD 

// 

DD 

// 

DD 

//PAYMSTR 

DD 


UNIT=011 
UNIT=012 
UNIT=013 
.UNIT=DISK 


IN THE ABOVE EXAMPLE GR0UP1 DCB DEFINES THREE LINES 
WHOSE SUBCHNL ASSIGNMENTS ARE 011,012, AND 013 
RESPECTIVELY 


BTAM-9 













DATA EVENI CONTROL BLOCK (DECB) 


o DECBs ARE AREAS IN APPLICATION PROGRAM USED TO 



SPECIFY 

THE 

DETAILS OF THE 

OPERATION 

THAT 

BTAM 


IS TO PERFORM 





o 

EACH READ 

OR 

WRITE OPERATION 

USES A 

DECB 


o 

AT MOST, 

NEED 

AS MANY DECBs 

AS THE 

NUMBER 

OF 


LINES IN 

THE 

NETWORK 





o UPON COMPLETION OF THE OPERATION BTAM RETURNS 

THE COMPLETION STATUS OF THE OPERATION IN THE 
DECB AREA 


APPL BTAM O S 


READ 

1 

1 

1 

1 

1 

1 

8 

1 

1 

1 

1 

EX CP 

1 

1 

I 

1 

1 

1 

1 

1 

1 

SIO 


1 

1 

; DECB 

• 

• 

1 

• 

D 

1 

CHNL : 



1 

1 

1 

• 

pgm : 
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BTAM CONSIDERATIONS FOR IBH 3270 


THE IBM 3270 FAMILY 

o FAMILY OF DEVICES: CONTROLLERS, CRTs, AND PRINTERS 

o MULTIPLE DEVICES, CRTs AND PRINTERS, ON ONE CONTROLLER 

o THE MOST COMMON DEVICE IN IBM MAINFRAME ENVIRONMENT FOR HIGH 
PERFORMANCE APPLICATIONS 

o EXTENSIVE CAPABILITIES IN CRTS AND PRINTERS FOR MESSAGE 
FORMMATING AND FORMS CONTROL 

o VERY COMPLEX FROM SOFTWARE POINT OF VIEW 
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IBM 3270 CONTROLLERS MODEL NUMBERS 

WITHIN THE 3270 FAMILY, DIFFERENT PROTOCOLS SUPPORTED BY DIFFERENT 
CONTROLLERS 


VARIOUS MODELS ARE: 

3271 MODELS 1 AND 2: BSC CONTROLLERS 

3271 MODELS 11 AND 12: SDLC, PU TYPE 1 CONTROLLERS 

3274, 3276: SDLC, PU TYPE 2 CONTROLLERS 


NOTE: SDLC CONTROLLERS CAN BE EQUIPPED WITH A BSC SWITCH WHICH 

ENABLES THEM TO OPERATE IN EITHER MODE. 
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REVIEW OF MULTIPOINT OPERATION 


HOST 


EOT 


POLL <WITH ID) 


: I 

!STATION ! 


V 


< 


RESPONSE FROM THE 
POLLED STATION 


1. ID IN THE POLL COMMAND IDENTIFIES WHICH STATION ON THE 
LINE IS PERMITTED TO RESPOND TO THE POLL 

2. EACH CONTROLLER ON THE LINE AND EACH OF ITS ASSOCIATED 
CRTs AND PRINTERS ASSIGNED 1 BYTE HEX ID 

3. PRE-ASSIGNED RANGE OF IDs 
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IDENTIFYING CONTROLLERS AND DEVICES 


CONTROLLER ID: 
2 TYPES 


POLLING ID: ID USED WHEN HOST WISHES TO RECEIVE. 

PERMISSIBLE IDs DOCUMENTED IN 3270 MANUAL . 

SELECTION ID: ID USED WHEN HOST WANTS TO SEND (ALSO 

KNOWN AS ADDRESSING ID). 

FOR EVERY VALID POLLING ID A PRE-DESIGNATED 
SELECTION ID - SEE TABLE IN 3270 MANUAL. 


POLL EXAMPLE 


EOT -*---—-> 

POLL ID ----— -—— > 

<— -- ——„—__> MSG OR EOT 

SELECTION (ADDRESSING) EXAMPLE 


EOT ----—--> 

SELECTION ID -—---> 

(ADDRESSING) 


< 


ACKO/1 


MESSAGE 


> 


ID CODE IMPLICITELY INDICATES WHETHER THE OPERATION IS A POLL OR 
SELECT. 
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CONTROLLER AND DEVICE IDENTIFICATION 


device id: 
2 TYPES 


GENERAL ID: USED WITH POLL OPERATIONS ONLY 

ANY DEVICE ON THE CONTROLLER MAY SEND DATA 
DEVICE ID X'7F* RESERVED TO SPECIFY GENERAL POLL 


SPECIFIC ID: ONLY THE SPECIFIC DEVICE IDENTIFIED MAY RESPOND OR RECEIV 



DEVICE A 
DEVICE B 
DEVICE C 


GENERAL POLL 


EOT -> 

(CNTRLR ID, X'7F’) -> 


< 


DEVICE A, B, OR C 
MAY SEND 


SPECIFIC POLL 


EOT -------> 

(CNTRLR ID, DEVICE A ID) —---— > 



ONLY DEVICE A MAY 
SEND DATA 
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TERMINAL LIST 


A LIST CONTAINING IDs OF VARIOUS DEVICES THAT HAVE TO BE POLLED 
OR SELECTED BY THE HOST SOFTWARE 

DIFFERENT LIST USED FOR POLLING AND SELECTION OPERATIONS 

DIFFERENT OPTIONS OFFER DIFFERENT DEGREES OF CONTROL AND 
EFFICIENCY 
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AUTO VS. MANUAL LIST 
(BTAM) 

WITH A MULTIPLE ENTRY TERMINAL LIST: 

AUTO LIST: 

o AUTOMATICALLY SERVES EACH ENTRY IN THE LIST 
o USED WITH POLLING (READING) OPERATIONS 

o REDUCES CPU OVERHEAD 

MANUAL LIST: 

o SERVES ONLY ONE ENTRY IN THE LIST IN ONE OPERATION 
(SOFTWARE SPECIFIES WHICH ENJRY) 

o USED WITH SELECTION/ADDRESSING (WRITE) OPERATIONS 
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OPEN VS WRAP LIST 


(APPLIES TO AUTO LISTS FOR POLL) 


OPEN LIST: 

STOP POLLING UPON RECEIVING A MESSAGE OR UPON REACHING 
END OF LIST 


WRAP LIST: 

UPON REACHING END OF LIST RESTART THE POLL AT THE 
BEGINNING OF THE LIST (WRAPAROUND) IF NO MESSAGE HAS 
BEEN RECEIVED 


BTAM-18 



DESCRIBING TERMINAL INFORMATION IN BTAM PROGRAM 


(name) DFTRMLST valuel,value2,.,value-n 


DFTRMLST: DESCRIBES 

TERMINALS 

ON 

LINE 

AND 

INFORMATION 

INFORMATION NEEDED 

BY 

BTAM 

TO 

MANAGE A 

SWITCHED 

LINE 





valuel,value2, ...., 

value-n: THERE 

ARE 

NO 

UNIVERSAL 


RULES FOR THESE VALUES WHICH ARE LINE AND 
DEVICE DEPENDENT. BTAM MANUAL PROVIDES PRECISE 
DETAILS FOR WHAT SHOULD BE CODED FOR EACH 
SUPPORTED DEVICE 

ONE OR MORE DFTRMLST DEFINITIONS ARE NEEDED FOR 
EACH LINE 

EXAMPLES FOR TWO COMMON DEVICE TYPES FOLLOW 
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TERMINAL LISTS FOR BSC 3270 


LIST01 


LIST2 


LIST03 


EXAMPLE l: AUTO-OPEN POLL LIST 

DFTRMLST AUTOLST,(404040402D,40407F7F2D, C1C17F7F2D,3737373737 


,3 


AAA 

CNTRLR ID_ S ! I _ENQ 

t 

I 

DEVICE ID 


EXAMPLE 2: 


AUTO-WRAP POLL LIST 


DFTRMLST AUTOWLST,(404040402D,40407F7F2D,C1C17F7F2D, 3737373737 


1 

I 

.1 


SK </** 


DEVICE ID 


EXAMPLE 3: 


SELECTION LIST 


DFTRMLST OPENLST,(606040402D) 

AAA 

CNTRLR ID_! ! !_ 

I 

I 

DEVICE ID 


ENQ 


I 

I 


I 


I 
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i 
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i 

i 

i 

i 

i 

i 

i 

i 

i 

i 

i 

i 


INFORMATION IN THE FOLLOWING 

PAGES CONTAINS ADDITIONAL 
DETAILS ABOUT BTAM MACROS 

AND CODING ORIENTED TOPICS 

IT IS INCLUDED IN HERE AS 

A FURTHER REFERENCE FOR 

THOSE INTERESTED IN THESE 

DETAILS 
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BTAM 


o 


o 


o 


o 


o 


INITIALIZATION and termination macros 


OPEN deb name 


OPENS A GROUP OF LINES REPRESENTED BY 
THE DCB IDENTIFIED 

CAUSES A COPY OF BTAM TO BE LOADED IN 
TO THE APPLICATION PARTITION 

ADDRESS OF WHERE BTAM IS LOADED IS PLACED 
IN THE DCB ITSELF 


CLOSE deb name 


TERMINATES AVAILABILITY OF BTAM FOR THE GROUP 
OF LINES IDENTIFIED BY THE DCB 

DISABLES LINES IN THE GROUP 
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BIAD_MACRQi_ACCEPTING_pATA_FROM_A_pEyiCE 


(name) READ DECB. OP TYPE, DCB, INAREA, MSGSIZE, 

TERM-LIST, REL. LINE, MF=E 

8 OPERANDS: 

DECB ADDRESS OF THE DECB TO BE USED WITH THIS 

READ OPERATION 


OPTYPE 


CHANNEL PROGRAM ID FOR THIS 10 


DCB NAME OF THE DCB ASSOCIATED WITH THIS LINE 

INAREA ADDRESS OF THE AREA WHERE APPLICATION 

WANTS BTAM TO PLACE THE INCOMING MESSAGE 


MSG_SIZE SIZE OF THE LARGEST POSSIBLE MESSAGE 

THAT CAN BE RECEIVED IN THIS OPERATION 


TERM .LI ST ADRRESS OF THE POLL LIST TO BE USED 

WITH THIS READ 

B§L i ._LINE WHICH LINE WITHIN THIS DCB GROUP IS 

BTAM TO READ FROM 


MF=E 


MACRO CODING REQUIREMENT, CODE IT AS SHOWN 
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WRITE MACRO: SENDING DATA TO A DEVICE 


(name) WRITE DECB, OP TYPE, DCB, MSGADDR, MSGSIZE, 

TERM-LIST, REL. LINE, MF=E 

8 OPERANDS: 


DECB 

SAME AS READ 

MACRO 




OPTYPE 

If II II 

II 




DCB 

II II II 

II 




MSGADDR 

ADDRESS OF THE MSG 

TO 1 

BE SENT 


MSGSIZE 

EXACT LENGTH 

OF THE 

MSG 

TO BE 

SENT 

TERM LIST 

ADRRESS OF THE 

SELECTION 

LIST FOR 

THE 


DEVICE TO 

WHICH 

THIS 

MSG IS 

ADDRESSED 

REL. LINE 

SAME AS READ 

MACRO 




MF=E 

II II II 

It 
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WAIT MACRO: WAITING FOR AN 10 TO COMPLETE 


1 . 

APPLICATION 

PROGRAM 

RESPONSIBLE 

FOR 

TELLING 


OS TO PUT 

IT TO 

SLEEP WHILE 

AN 

EVENT IS 


BEING COMPLETED 

2. EVENT BEING WAITED UPON IS IDENTIFIED VIA 
AN EVENT CONTROL BLOCK (ECB) WHICH IS IN 
THE DECB ITSELF 

3. APPLICATION CAN WAIT ON SINGLE OR MULTIPLE 
EVENTS 

4. APPLICATION MUST ENSURE THAT AN 10 GOT 
STARTED SUCCESSFULLY BEFORE ISSUING A WAIT 

iXAMPLE_ll_SINGLE_EVENI_WAIT 

WAIT ecb name 

WHERE ecb name IS THE SAME AS DECB NAME 

EXAMPLE 2: MULTIPLE EVENT WAIT 


WAIT count,ECBLIST® address o-f a list 

o-f ECBs 


count 

IN 

THIS 

CASE 

SPECIFIES 

HOW 

MANY 

OF 

THE 

EVENTS 

IN 

THE 

LIST MUST 

COMPLETE 

BEFORE 

THE 

APPLICATION 

IS 

TO BE *WOKEN' 

UP 
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iBRQB_ANALYSIS_IN_BIAM_APPLICAXION 

1. ON CERTAIN TYPES OF ERRORS BTAM WILL RETRY 

AN OPERATION MULTIPLE TIMES AND IF THE ERROR 
STILL PERSISTS IT WILL REPORT IT TO THE 
APPLICATION 

2. IT IS THE APPLICATION RESPONSIBILITY TO INITIATE 
ANY FURTHER RECOVERY 

3. ALL INFORMATION PERTAINING TO THE ERROR IS 

RETURNED IN THE DECB 

4. ERROR ANALYSIS AND RECOVERY PROCEDURES CAN BECOME 
FAIRLY COMPLEX AND HIGHLY DEVICE DEPENDENT AND 
GENERALLY SEPERATE ROUTINES ARE CODED FOR 
DIFFERENT TYPES OF DEVICES 
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BTAM REVIEW QUIZ 


(TRUE/FALSE) 

THE 

DCB 

CONTAINS 

THE 

ADDRESS OF BTAM 

AFTER IT 

PARTITION. 

HAS 

BEEN 

LOADED 

IN 

THE APPLICATION 


2. WHICH INSTRUCTION (MACRO) IN THE APPLICATION PROGRAM 
CAUSES BTAM TO BE LOADED IN ITS PARTITION? 

3. A CONTROL BLOCK USED TO PASS INFORMATION BETWEEN 

BTAM AND APPLICATION IS CALLED THE _. 

4. THE MACRO (TABLE) USED TO DESCRIBE THE TERMINAL 

OR SWITCHED LINE INFORMATION IN BTAM IS CALLED THE 


5. (TRUE/FALSE) THE INFORMATION CONTAINED IN THE TERMINAL 

LIST IS DEPENDENT ON THE TERMINAL TYPE. 

6. IN A BTAM ENVIRONMENT THE APPLICATION PROGRAM MUST ENSURE 
WHETHER AN I/O WAS STARTED AND COMPLETED SUCCESSFULLY 
BEFORE TRYING TO PROCESS INFORMATION ASSOCIATED WITH THE 
I/O. 

AFTER ISSUING A READ/WRITE MACRO, REGISTER 15 

INDICATES WHETHER THE I/O WAS __AND 

VARIOUS FIELDS IN THE DECB INDICATE WHETHER THE I/O 
WAS 


7. WITH REFERENCE TO QUESTION b ABOVE, WOULD ONE TEST 
REGISTER 15 FIRST OR THE CONTENTS OF DECB TO PROPERLY 
CHECK I/O OPERATION STATUS? 

8. (TRUE/FALSE) AN APPLICATION MUST WAIT FOR AN I/O 

OPERATION TO FINISH COMPLETELY BEFORE IT MAY START ANY 
FURTHER I/Os ON OTHER LINES IN THE NETWORK. 


BT AM-27 











UNIT 4 


TELEPROCESSING MONITORS AND BTAM 


objectives 

TO IDENTIFY MAJOR COMPONENTS OF A 
TELEPROCESSING MONITOR 

TO IDENTIFY REASONS WHY AN MIS ORGANIZATION 
WOULD NEED A GENERAL PURPOSE TELEPROCESSING MONITOR 

I TO EXPLAIN DIFFERENCES BETWEEN OPERATING SYSTEM, 
ACCESS METHOD, AND TELEPROCESSING MONITOR 
yVj FUNCTIONS 

TO IDENTIFY TRADE-OFFS BETWEEN DEVELOPING YOUR 
OWN TELEPROCESSING MONITOR VS. LEASING OR 
BUYING A PACKAGE 

TO DISTINGUISH BETWEEN ' MULTIPROGRAMMING’, 
'MULTITASKING’, AND 'MULTITHREADING’ AS USED IN 
IBM PUBLICATIONS 
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WHY 


T P 


MONITORS? 


THE 


REASONS THEN 
- BTAM, 3705 / EP 


THE REASONS 
- SNA 


NOW 

PROTOCOLS 
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The software technology has evolved at a very rapid 
pace. Thus, before one answers a question such as 
the above one almost has to know the point in time 
when the question is being answered. 

Some of the major reasons why TP monitors came about 

during the days of BTAM have since disappeared and, 
yet, TP monitors are still very much around ! Well 

the old problems have been replaced by new problems - 

SNA protocols. More on that later. 

In any case, to answer this question in the context 
of BTAM one has to go back in history (yes in 

this industry a 15 years lapse qualifies as history) 
and look at the state of the art in software 

technology in existence then. 

What were the constraints under which a customer 

developed communications software on an IBM mainframe 

in those days ? 

Let us next review the environment in existence 

then. 


J 
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I 

I 

I 

I 

I 

1 

I 

I 

l 

1 

i 

I 

I 

1 
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THE REASONS THEN 


CIRCA MID 60s 


ADVENT OF THE FIRST GENERATION OF GENERAL PURPOSE 
COMPUTING MACHINES- IBM SYSTEM 360 


A NEW GENERATION OF SYSTEM SOFTWARE- OS/360 

NEW FAMILY OF COMMUNICATIONS FRONT END CONTROLLERS- IBM 
270X FAMILY 

A "COMPREHENSIVE" NEW ACCESS METHOD FOR COMMUNICATIONS- 
BTAM 

INCREASING PRESSURES ON TECHNOLOGY TO PRODUCE MORE 
TIMELY INFORMATION 

IBM 3270 AND BSC PROTOCOLS ARE STILL A FEW YEARS AWAY 
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WHAT 

DID AN END 
IN SUCH AN 

PRIOR TO TP 


USER DO 

ENVIRONMENT 

MONITORS? 


r -. 


f»r- i 


ULj 




I 


I 

I 

I 

1 

I 

I 
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XYZ i _INC i i_AN_ENp_LJSER_SCENARig_iLATE_60s2 


XYZ, Inc is a relatively enlightened D. P. user. While 
the top management does not fully understand the technology, 
they have given a free hand to their Director of Data 
Processing Systems who in turn reports to the V. P., 
Corporate Finance. 

Because of the rising popularity of their main products, 
Widgets and Gizmos, XYZ has been opening various regional 
offices and distribution centers. 

Corporate headquarters are located in St. Louis with 
regional locations in New York, Chicago, Dallas, Houston, 
Los Angeles, and San Fransisco. 

Because of an accelarated growth rate a few things got out 
of hand. One of the major problems was managing the 
inventory at regional locations. While they were carrying 
excessive inventories in large number of items and, 
therefore, paying high interest payments, paradoxical ly, 
they were consistently running short on other items in 
demand causing shipping delays and order cancel1 ations. 

That. is when they did it for the first time. 

Their first on-line system using TTY33 teleprinters! 

Each regional distribution center was installed with a TTY33 
machine and the centers could dial into the central 
computer at St. Louis two or three times a day and report 
critical inventories. 

Results, were satisfactory and directors of Data Processing 
and Operations were promoted to newly created positons of 
Corporate Assistant Vice Presidents. 

And then it happened ! 


x x x x x x 


VP Marketing felt that sales force was spending too much 
time doing the paperwork and had no way of tracking the 
orders within the corporation. He demanded an on-line 
capabi1ity. 
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VP Corporate Finance was still smarting over the -fact that 
she was the one to discover the inventory problems but 

the credit had gone to the operations people. She 
wanted more timely information on cash flows, short term 

borrowings and surplus cash that could be invested in short 
term commercial paper. She too wanted an on-line 
capabi1ity. 

Manufacturing managers wanted a direct access to Marketing 
and Distribution data so that they could schedule production 
more accurately. Why not an on-line system for them too? 

AVP Data Processing, while happy at the potential 
increase in the size of his corporate domain, was also 

concerned about his ability to fulfill all the requested 
requirements. On-line technology was still too new for him. 

So, after due consideration, or at least the appearance of 
it, he made the following recommendations: 

1. Corporate Finance would be provided with an on-line 

access to corporate financial data bases. This would 

enable the finance people to make on-lihe inquiries 

against the data base and also provide certain 
on-line reports on request. 

2. Marketing would have an on-line order entry and 

inquiry/response system to track orders. 

3. Manufacturing Department needs could be met via more 
timely batch reports and, for now at least they did 
not have a real case for an on-line system 

To make it all happen, AVP, D P proposed that: 

1. Given the reliability requirements and sensitive nature 
of data, the system would consist of private lines 
only. 

2. XYZ would use a new family of terminals from IBM called 
3270s that had recently been announced. 

3. Since terminals were going to be located in the same 
cities, the cost of private lines could be reduced by 
connecting terminals for various applications on the 
same private line (3270s could be 'clustered'' on a 
line). 

4. To keep the system simple and maintain data security 
and integrity each application wi11 be a seperate, 
independent job in the system. 
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5. All software development, as always, would be done in- 
house to ensure a high quality, tailor-made, and high 
performance system. 

6. To do all this the current machine would have to be 
upgraded -from IBM System 360 Model 40 to Model 55 and 
with additional personnel requirements the DP budget 
would have to be increased by at least 50%. 

But -for a -few objections regarding the high cost and lack of 
need analysis from the Manufacturing Department, the plans 
for the new system were quickly approved by the corporate 
Policy Committee. 

Design and analysis work was started by the design team. 

A few programmers were sent for BTAM and 3270 training and 
the first substantial report from the system design team was 
presented to the AVP Data Processing about six months later. 

Once the team members were done with all the nice features of 
BTAM and 3270s they had one little surprise for the AVP/DP. 

The system could not be implemented to support the exact 
configuration as approved by the policy committee. They 
assured him that there was no major problem - they would 
just need a few more private lines. 

And then the system design team provided the explanation 
as to why the configuration could not be implemented 
precisely as approved. 
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X Y Z A I NC i _PROBLEM_ ANALYST S 


The network and host configurations as approved by the 
XYZ Policy Committee for the 3 on-line applications 
are shown on the next two pages. 

Analyze the configurations and see if you can identify 
the reasons why it cannot be implemented precisely 
as shown. 

Once you discover the reason you should probably be 
able to state it in less than 5 sentences. 

We shall discuss your answer in a few minutes. 
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PROPOSED HOST CONFIGURATION 


• 

! FINANCE : 

BTAM 


m 

! MKTG S 

BTAM 

0 


! DIST : 

BTAM 

S 



I 

I 

BYTE MUX 
I/O CHNL 

IBM SYSTEM 360/50 
OS / MVT 


2701 


LI 

L2 

L3 
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BEFORE I AFTER 
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COMBINING THREE PROGRAMS INTO A SINGLE JOB: 


Questions that must be answered: 

1. How do you bring three programs in the same 

partition? 

2. When a message comes in, how do you know who 
is going to process it and who is this 'you' 
who is going to do the -figuring? 

3. Are all operators authorized to access all 

available programs or are there to be any 

restrictions? 

If restrictions, who is going to enforce 
them? 


4. OTHER ISSUES... ? 
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TRANSACTION CONTROL PROGRAM 
(FUNCTIONAL DESCRIPTION) 



TPMONS- 17 




SWITCHING CONTROL FROM ONE TRANSACTION TO ANOTHER 




GIVEN: 3 MESSAGES IN THE HOST 

MESSAGE 1 IS CURRENTLY BEING PROCESSED 
MESSAGES 2 AND 3 ARE AWAITING PROCESSING 


QUESTION: WHAT IS THE EARLIEST TIME THAT MESSAGE 2 
CAN BE PASSED TO FNCL? 
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Switching control f rom_one_ transact ion t o_arigtherl 


In the example shown here we have currently 3 
messages in the host machine. 

Message 1 is for MKTG transaction. It was the 
1st one to arrive and is currently being processed 
by the MKTG program. 

Messages 2 and 3 arrived next in that order. 
Question is - 

What is the earliest that we can start processing 
message 2 without unduly disrupting message 1 
processing? 
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TO O PBRAKCHS AS CRITERIA FOR 
.SWITCHING TR AK/.^ACT I QMS : 
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I/O a s a c riterion f or n switching .T ransactions; 


As a starting point it may be worthwhile to borrow 
a concept -from the Operating System that it uses to 
implement multiprogramming i.e. switching -from one 
job to another during an 10 operation. 

We want to switch •from MKTG to FNCL during an 10 
operation for MKTG. 

Except that instead of the Operating System it is 
the Transaction Control who would have to make the 
switch. 

How is the Transaction Control going to do it? 

Let us review again some of the facts about flow of 
control in an I/O operation next to help us 
determine the Transaction Control logic. 
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QPPLICAIIQN_ig_REQyESIi_ELQW_QF_CgNIRQL 

MKTG 

] MKTG START ! 

I • • 

I ■ • 



TRANSACTION 

CONTROL 


TO 

CHANNEL 
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AqqI ication I/O Re qu est: Ff ow of Control,X. 


The diagram on the opposite page shows the relevant part 
of the -flow when an application issues an 10 
request. 

There are three m aj o r transitions of interest: 

1. Application issues an OS access method macro. The 
macro generated code causes a branch to the access 
method. 

2. The access method eventually issues an EXCP 
instruction, which in turn transfers control 
to the 10 Supervisor in the Operating System. 

3. The 10 Supervisor issues SIO, thereby, 

starting the Channel operation. 

The interesting fact about this flow is that ft 

completely b ypasses. p ur T ransaction C ontrol. 

If the Transaction Control is to do any program 
switching, it has to know when one of our transactions is 
doing an 10 operation. 


Worse yet, if any of the transactions were to request OS 
to be put in a WAIT state, it would cause the whole 
partition to be put in a WAIT state including the 
Transaction Control and all the other transactions - a 
highly undesirable situation. 

One way to get around our problems is not to let the 
transactions make direct 10 requests or issue any WAIT 
requests. 


Any time a 
transaction 
requirements, 
actual 10 
then can 
from one 
operation. 


transaction needs an 10 operation, the 
will inform the Transaction Control of its 
and only the Transaction Control will issue 
requests and any WAIT requests. Only 
the Transaction Control transfer control 
transaction to another during an 10 
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Application 10 request: F low^o-f_control j with 
Transaction Control 

1. The transaction MKTG sets up details of the 10 
operation - name o-f the -file, record ID, and whether 
or not it can do more processing while the 10 is taking 
place and goes to the Transaction control. 

2. Transaction Control -formats an access method request 
based upon transaction provided data. Transaction 
Control also indicates to the OS that it not 
be put in a WAIT state while the 10 is progressing. 

3. A-fter initiating the 10 request -for MKTG the 
Transaction Control also goes through its internal 
tables to see i-f any transaction can do any processing 
(new messages may have arrived or some prior 10s may 
have been completed). 

4. I-f any other transaction can proceed at this time, say 
FNCL in this case, Transaction Control would transfer 
control to such a transaction. 

This stefi is the very essence of managing 

multifile transactions in a single jobj. 

5. If, however, no further work can be dispatched at this 
time, the Transaction Control would issue a WAIT 
request to the Operating System. 

An ability such as above whereby Transaction Control can run 
multiple programs (tasks) concurrently within a 
partition/job/region/address space is called multitasking. 

XYZ, Inc. would have to develop a multitasking Transaction 

Control program if they want to run the three transactions 
concurrently over a shared network as they proposed 
to do. 
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MULTIPLE MESSAGES FOR THE SAME TRANSACTION 


FNCL 


MKTG 

L_- 

01 - 

-102- 

-103- 


DIST 


L 



TRANSACTION 

CONTROL 


© 

I MKTG 


© 

MKTG 1 
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Multiple c oncurrent ^ messages -for t he_same_transaction: 

Take a situation in our on-line system where we have three 
messages in the system: 

1. As Transaction Control comes through its next pass to 
check -for dispatchable work it discovers message 1. 

Based upon our system design, the Transaction Control 
looks at the transaction ID and determines that MKTG 
transaction is to process this message. 

2. Message 1 is dispatched to MKTG and that transaction 
starts running. 

3. MKTG starts processing message 1 and ultimately needs a 

record -from one o-f its files and sends a request for an 
10, 101, to the Transaction Control. 

4. Transaction Control notes down the the location within 
MKTG where the program is to be restarted when 101 
completes and sets up the 10 request for MKTG. 

5. Transaction Control now looks for additional work that 
can be dispatched and discovers that message 2 is ready 
for processing and that this too is for MKTG. 

6. Transaction Control interrogates the status of the 
MKTG transaction and finds that MKTG is awaiting an I/O 
completion and, thus, temporarily idle. 

7. Transaction Control transfers control to the 
beginning of the MKTG transaction passes it message 2 
for processing. 

At this time the MKTG program is in effect processing 
two messages 'concurrently’ or, in other words, we have 
two seperate processing threads running through the 
same program. 

This process whereby a single program can process multiple 
messages concurrently is called multithreading. 

Programs that can multithread are also called reenterant 
programs because they can be 'entered' again while they are 
still processing a previous message. 
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MANAGING JHE NETWORK 

So far our discussions have focussed primarily on activities 
within the host. We shall next take a look at functions that 
have to be performed to manage the network. 

These functions would involve tasks such as 
activating/deactivating lines, responding to incoming calls 
on switched lines, starting polls on private lines and 
functions such as were discussed in the BTAM lecture. 

First question, irrespective of the details, is one 

pertaining to the overall structure of our system. 

Should these additional functions be performed by the 
Transaction Control module or do we have a better idea? 
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TRANSACTION CONTROL AND NETWORK MANAGER 



TRANSACTION CONTROL MANAGES TRANSACTIONS j 

NETWORK MANAGER MANAGES NETWORK 

I 

I 

I 

I 

I 

I 

I 
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Transaction Control, and Network Management Program 


Our on-line system has so -far 
components: 

Transaction Control: 

Network Management Program: 


evolved to two major system 


For managing the transactions 
For managing the network, -for 
brevity, we would refer to it 
as the Network Manager. 


Next we would explore how communications take place between the 
Network Manager and the rest o-f the system. 
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COMMUNICATIONS BETWEEN NETWORK MANAGER AND SYSTEM COMPONENTS 
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Communications between.Networ k .Manager and other 
system. co mp onentsL 

Earlier in this unit we discussed reasons why transactions 
must not issue requests directly to the Operating System - 
but rather route their requests to the Transaction Control. 

For similar reasons we would also require that there be no 
direct communications between transactions and the Network 
Manager. The requests for network services from 
transactions would also be routed through the Transaction 
Control. 

The two major advantages of such an approach are: 

1. The Transaction Control has total control over the 
system and can keep track of each transaction's 
progress and put transactions in a WAIT state if they are 
awaiting completion of pending events. 

2. The fact that there is a Network Manager is totally 
transparent to the transactions. The transactions need 
a single interface to the Transaction Control program 
irrespective of the type of service needed. The 
Transaction Control would take care of routing the 
request to the appropriate system component. 

We shall next take a look at the overall flow of the system 
as it has evolved so far. 
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FLOW OF CONTROL BETWEEN TASK CONTROL AND NETWORK MANAGER 
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Overal l S ystem._ F l.ow: 


Transaction Control is basically a cyclical program that 
runs in a big logical loop and keeps dispatching 
transactions as messages arrive in the system or 10 

activities complete. It must also periodically dispatch the 
Network Manager to send or receive messages -from the 
network. 

Because o-f this circular logic we can pick up the 

Transaction Control logic anywhere in the cycle and complete 
the circle. In the -flow chart shown here we pick up the 
logic at a point where the Transaction Control has just 
received control back -from a transaction. 

1. Transaction Control takes transaction request, if any, 
along with any other pending requests -from before, 

2. sets up 10s 

3. At this point the transaction Control branches to the 
Network Manager so that the Network Manager may report 
completions on previously started I/Os and start new 
10s, 


Networ k Manager: 

a. Scans control blocks for each line. 

b. As completed 10s are discovered posts them 

in appropriate control blocks for the 

Transaction Control. 

c. Starts new READ/WRITE operations on idle 
1ines. 

4. Transaction Control scans the control blocks posted by 
the Network Manager to check if completions were 
posted and 

5. Marks those transactions dispatchable 

that can start processing. 

6. Transaction control now scans the list of dispatchable 
tasks in priority order and 

either, 7. Dispatches a transaction 

or, B. Requests an OS WAIT with an ECB list 

of all activities pending completion. 
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ISSUES FOR SYSTEM PROGRAMMER 


HOW AND WHERE TO MAINTAIN: 

LINE STATUS: ACTIVE / INACTIVE 

LINE TYPE: PVT / SW / SS / BSC1, 2, 3 

TERMINAL LISTS: POLLING / SELECTION 

DECBs 

10 ARAES 


BTAM PROVIDED MACROS (TABLES) 

DCB 

DECB 

DFTRMLST 

NEED FOR USER PROVIDED CONTROL BLOCKS? 


TPMONS—38 




Issues f or System D esigner 


To manage the network in a manner as shown in the system 
■flow diagram we would need information in the program that 
goes beyond what is provided via standard BTAM tables. 

For example,, while terminal lists can be defined using 
DFTRMLST macro, a mechanism is needed to determine which 
list is to be used when and with which line. 

It is important to identify the types of information that 
would be needed and how various inter—related data would be 
linked together. 

One way to put together such information is to put it in 
user defined tables or control blocks. The names, size, and 
contents of such tables are entirely upto the system 
designer. 

As an example of how information could be organized 
to implement a system such as here some illustrative tables 
are shown in the following pages. It should be borne in 
mind that this is just one of several ways tables could be 
organized i.e., there is no “THE WAY'. 

Generally speaking, though, it is a good idea to 
organize your tables in a heirarchical manner should 
there be natural heirarchical relationship among the 
resources being defined 
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BTAM and TP Monitors 


Overview of Control Blocks: 


SYSTEM AREA 
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GROUP ENTRY 
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Line Entry 


0 

,E~ 

C 

B 


ECB 


STATUS! 


ADOR OF NXT LINE ENTRY 


ADDRESS OF POLLIST 


ADDRESS OF DUMMY SELECTION LIST 
ADDRESS OF TERMINAL TABLE 

ADORESS GROUP _ 

ADORESS OF LINE 10 AREA 
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TERMINAL ENTRY 


I 

I 

I 


SYMBOLIC NAME 
CURRENT TRANSACTION 
SELECTION SEQUENCE 
LINE ENTRY ADDRESS 








I®iSBC2£SSSiD3 Monitors 


We just designed one! The concepts that we have developed 
so far in this unit. Transaction Control and Network 
Manager, in effect from the heart of real life TP Monitors 
such as CICS, Taskmaster, etc. 

The real life TP Monitors, of course, go far beyond our 
primitive model here. 

For example, we did not touch upon the data base handling 
at all in our model. In a real monitor this would be a 
major component. 

Other issues relate to storage management, high level 
language interfaces, handling application program errors, 
and system restart and recovery. These issues go beyond the 
scope of this course and cannot be covered here in any 
detail. However, we would discuss two monitors at an 
overview level later in this seminar. 
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Chapter II, Circa 1976 


XYZj. InCii 

Rich Star, V.P. Data Processing, is a respected executive 
of XYZ, Inc. Ever since he provided on-line systems -for the 
Marketing, Corporate Finance and Distribution departments, 
his star has been rising at XYZ. His promotion to V. P. 
came in late 1974 and Rich -felt that it was well deserved. 

Since XYZ was a dominant vendor by now, its executives were 
o-f ten invited to present keynote addresses by various trade 
groups and societies. 

One o-f such invitations was received by Jack Grouch, V. P. , 
Manufacturing, to be the keynote speaker at the annual 
convention o-f National Union o-f Retail Di str i butors, 

otherwise known as NURDS. 

While attending that convention at Hilton Head, South 
Carolina, Mr. Grouch heard a presentation by an independent 
consultant, Jane Smart, on use o-f computers in business. 

What especially caught Mr. Grouch's attention was Ms. 
Smart's assertion that it was becoming increasingly easier 
to develop on-line systems using pre-packaged software 
called Teleprocessing Monitors. Ms. Smart also talked about 
some rather complicated technologies using terms such as 
System Network Architecture, universal protocols, and 
machine-to-machine interfaces. 


Mr. Grouch 
presentation 
line system 
presentation 


was quite convinced after Ms. Smart's 
that Manufacturing had been denied their on- 
unfairly and invited Ms. Smart to make a 
to XYZ, Inc.'s Executive Committee the 


following month. 


Ms. Smart's presentation to the XYZ Executive Committee 
went rather well and the high point came when Ms. Smart 
disclosed that she had recently helped install a truly state 
of the art on-line system for XYZ’s main competitor, We 
Do It Better, Inc. Ms. Smart explained how Better’s 
system was developed using far less manpower and talent 
than XYZ using a package called Customer Information 
Control System (CICS), and how this system gave a tremendous 
advantage to 'Better' over their competition. 

Around the same period, unknown to DP staff, the CEO of XYZ 
was also approached by the Regional Marketing 
Director of IBM about the use of their latest software 
and hardware for XYZ. Their specific recommendation was 
to do a complete study of XYZ operations and to come up 
with a comprehensive solution for XYZ needs. 
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Such a study was undertaken and it was recommended that, 
looking into the -future, XYZ must consider migration to 
SNA and that IBM would provide software such as CICS to 
ease the pains of such a migration. 

Rich Star tried to point out how XYZ had one of the most 
efficient and reliable systems by industry standards. He 
also felt that migrating to SNA was premature. No one 
really understood the implications of such a move. However, 
Star was unable to provide any firm estimates of cost and 
time to migrate his current system to SNA other than to say 
that it would be almost like designing a whole new system. 

In 1975 XYZ migrated to CICS. The response time was less 
than desirable. When the system went down, it took much 
longer to bring it up because system programmers were not 
familiar with the system. But a whole new group of 
application programmers was very happy. They could write 
new transactions using Cobol . 

Rich Star had opposed the move to packaged_software rather 
strenuously. But it did not really matter any more. 

Last we heard. Rich was running a computer store selling, 
among other things, packaged software for micro-computers. 

Epilogue 

1977: Things were much better - but they had to migrate to 

the new release of CICS, 1.1.3, so that they could 
take advantage of the new features. 

1979: Things were much better. Release 1.1.3 was stable 

enough but they had to migrate to release 1.1.4. 

1981: Things were much better - but all the new exciting 

things were happening in SNA - perhaps it was time 
to consider ACF/VTAM version of CICS. 

1983: Things myst be much better, after all they were 

running SNA!! But who could be sure anymore. 
The largest communications company in the USA had 
just announced their new Value Added Public 
Network and there was talk of 'peanuts’ and 

'popcorn’ from IBM- they just had to look into it. 

1987: Things were much better, but ...... 
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XYZ, INC 

LESSONS TO BE 



L-EARMED 
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UNIT 10 


CUSTOMER INFORMATION CONTROL SYSTEM 
(C I C S) 


OBJECTIVES 

TO IDENTIFY MAJOR MODULES IN CICS 

TO IDENTIFY MAJOR TABLES IN CICS WITH MAJOR 
EMPHASIS ON TERMINAL CONTROL TABLE (TCT) 

TO PROVIDE OVERVIEW OF APPLICATION PROGRAM AND 
CICS COMMUNICATIONS 
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CICS INTRODUCTION 


o A GENERAL PURPOSE TELEPROCESSING MONITOR 

o AN IBM SOFTWARE PACKAGE (PROGRAM PRODUCT) THAT 

SIMPLIFIES THE TASK OF DEVELOPING SOFTWARE FOR ON¬ 
LINE APPLICATIONS 

o OTHER PACKAGES THAT PROVIDE SIMILAR CAPABILITIES: 

ENVIRON, SHADOW, TASKMASTER, IMS/DC 

o CICS, THROUGH ITS TASK MANAGEMENT CAPABILITIES, ALLOWS 

MULTIPLE APPLICATIONS (TRANSACTIONS) TO SHARE A COMMON 
NETWORK 

o APPLICATIONS MAY BE WRITTEN IN HIGH LEVEL LANGUAGES 


BESIDES 

REGULAR 

FILES 

ALSO POSSIBLE 

TO 

ACCESS 

DATA- 

BASES 

DEFINED 

UNDER 

PACKAGES SUCH 

AS 

IMS/DB 

(DL/I), 


IDMS, ADABAS ^ TOTAL ETC. 

o ERROR HANDLING, RECOVERY, SECURITY, PRIORITIES BY 

TERMINAL, TRANSACTION OR OPERATOR ARE SOME OTHER 
HIGHLIGHTS 
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SELECTED MANAGEMENT MODULES IN CICS 


TASK CONTROL: 
TERMINAL CONTROL: 

FILE control: 

/ 

STORAGE CONTROL: 

TEMPORARY STORAGE: 

PROGRAM CONTROL: 
JOURNAL CONTROL: 


DISPATCHES AND MANAGES PROGRAMS. 

MANAGES THE NETWORK AND TERMINALS. 

MANAGES THE FILES, INTERFACE TO ACCESS 
METHODS AND DATABASE MANAGEMENT SYSTEMS. 

MANAGEMENT OF STORAGE IN THE POOL BOTH 
FOR CICS OWN USAGE AND APPLICATIONS. 

"SCRATCH PAD" AREA, TO SAVE INTERMIDIATE 
RESULTS, DATA. 

LOADING OF PROGRAMS, LANGUAGE INTERFACE 
RECOVERY 


DUMP/TRACE CONTROL 


GENERATION OF DUMPS AND TRACES 





MAJOR tables in cics 


PROGRAM CONTROL TABLE (PCT): 

IDENTIFIES VARIOUS TRANSACTION CODES AND PROGRAM ASSOCIATED WITH 
EACH TRANSACTION CODE. 

PROCESSING PROGRAM TABLE <PPT>: 

NAMES OF ALL PROGRAMS THAT ARE TO RUN UNDER CICS, ONE ENTRY PER 
PROGRAM. 

PROGRAM ATTRIBUTES - LANGUAGE, SIZE, LOCATION ON DISK. 

TERMINAL CONTROL TABLE (TCT): 

DESCRIPTION OF NETWORK RESOURCES - LINES AND TERMINALS 

FILE CONTROL TABLE (FCT) : 

DESCRIPTION OF FILES NEEDED BY PROGRAMS THAT ARE TO RUN UNDER 
CICS. 

SIGN ON TABLE (SNT): 

USER NAMES, PASSWORDS, PRIORITIES, SECURITY KEYS. 
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CICS STRUCTURE 







CICS SYSTEM MODULES AND TRANSACTIONS RUN AS ONE JOB IN THE SAME 
ADDRESS SPACE (PARTITION) 

THE TASK CONTROL PROGRAM (KCP) ACTS AS THE INTERFACE BETWEEN 
APPLICATIONS AND CICS INTERNAL MODULES 


KCP: TASK CONTROL PROGRAM, FCP: FILE CONTROL PROGRAM, TCP: TERMINAL CONTROL PROGRAM , IMS: BASIC NAPPING SUPPORT 
JCP: JOURNAL CONTROL PROGRAM. 
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APPLICATION AND CICS COMMUNIACTIONS 


I 

[ 



I 


r? 



TCA: TASK CONTROL AREA/ ONE PER CICS TASK 


1 CSA: COWON SYSTEM AREA/ ONE PER CICS 

[ 
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BTAM AND CICS 


TERMINAL CONTRO TABLE <TCT> 


CONTAINS PROFILES OF ALL NETWORK RESOURCES, TABLES (DCB, DECB,..) 
NEEDED BY BTAM 


CICS MACROS INTERNALLY GENERATE BTAM MACROS 



DFHTCT TYPE=SDSCI 




DFHTCT TYPE=LINE. 


... A 


DFHTCT TYPE=TERMINAL, 


DFHTCT TYPE=LINE, 


DFTRMLST 


DFTRMLST 


Un 



TCA/1. 







<rr> r >i-'L t, 


.-A 11 
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BTAM AND CICS 


Jerminal. Control. Jabl.e _(JCTj.: 

All network defi nit ions are defined in the Terminal Control 

Table (TCT). The TCT contains information not only neede ny CICS 

but also information that it would need to communicate with BTAM. 
BTAM macros DCB and DECS are not coded directly by the system 

programmer but are generated internally by CICS. 

The same macro, DFHTCT, is used to describe all types of network 
resources. TYPE= operand identifies the resource being 

described. 

TYPE * SDSCI: Describes a group of similar lines, and generates 

the BTAM DCB table. Needed one per group of 
similar lines. 


TYPE= LINE: Describes the profile of one line in the group. 

Coded as many times as the number of lines in the 
system. Also generates the DECB for the line . 

TYPE= TERMINAL: Describes a controller or device on the line. 

Coded once for each or controller or device in the 
network. 


DFHTCT: This is the standard BTAM macro and coded as 

discussed earlier in this course. 
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ILLUSTRATIVE OPERANDS FOR TERMINAL CONTROL TABLE 
IN CICS 


DFHTCT TYPE-INITIAL, 

ACCMETH-NONVTAM, 


BEGIN TABLE 
NON-VTAM SYSTEM 


AUTOWLST,(...poll list..) 

OPENLST,(...sel list..) ONE PER DEVICE 


POLLST1 DFTRMLST 
SELLST1 DFTRMLST 

a 

a 

a 

DFHTCT 


DFHTCT 

DFHTCT 


TYPE-SDSCI, 
DEVICE-3277, 
DDNAME-. 


TYPE-LINE, 
BTAMRLN-..., 
LISTADDR=POLLSTl 


TYPE=TERMINAL, 
TERMID=T001, 
TRANSID=ACCT, 
TRMADDR=SELLST1, 


GROUP ENTRY 

FOR 3270 TYPE 
JCL CONNECTION 


BEGIN LINE DESCRPN 
WHICH LINE IN JCL 
POLL LST THIS LINE 


BEGIN TERM DESCRPN 
LETS CHRISTEN IT 
OPTIONAL DEFAULT 
TERM SEL LST NAME 



DFHTCT TYPE-FINAL END TABLE 
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CICS_AND BASIC MAPPING SUPPORT (BMS) 


MOSI TELEPROCESSING MONITORS IQDAY OFFER AN APPLICATION 
CODING AID OFTEN REFERRED ~TO _ A§ ^MAPPING SUPPORX1 

examples of such featur|| "are?" 

o BASIC MAPPING SUPPORT IBMSii CICS 

9 MESSAGE FORMATTING SERVICES iMFSii IMS 

2 IERMINAL INDEPENDENCE MODULES illMSH 

TASKMASTER ETC? 


PRIMARILY A CODING AID TO EXPLOIT 3270 CAPABILITIES WITHOUT 



REQUIRING an application programmer io know about; command 

AND DEVICE LEVEL DETAILS QF 3270.. /I'h u < 

’~$- c i4 " n jt-*&-**** f ~ 

a / /. ./-■ / *" 




A VERY USEFUL TOOL WHICH REMOVES LARGE AMQUNTS OF CLERICAL 
AND ERROR PRONE DETAILS FROM THE APPLICATION PROGRAM CODING. 


LACK OF DEVICE FAMILIARITY CAN ALSO GIVE RISE JO SOME 
VERY POORLY DESIGNED APPLICATIONS WITH RESPECT TO 3270 
DEVICES 


FOR APPLICATIONS DEALING WITH A VARIETY OF DEVICES 
MUUHPLE 'MAPS' CAN DEFINED^ ONE FOR EACH DEVICE AND 
CAN BE GROUPED IQGEIHER AS A ’MAP-SET' FOR CONVENIENT 
REFERENCE IN THE APPLICATION. 
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EXERCISE 


I 

FOR THE NETWORK CONFIGURATION USED IN THE BTAM 

EXERCISE, CODE THE APPROPRIATE CICS/TCT MACROS IN J 

THE RIGHT ORDER. CODE ONLY THOSE VALUES THAT WERE 
SHOWN ON THE ILLUSTRATIVE TCT VALUES. I 

(NOTE: FOR TTY-43 TERMINAL DEVICE CODE ry 

CODE TRMTYPE=TWX ON TERMINAL DESCRIPTION) 

bfc 

1 

I 
1 
1 
1 
I 
I 
1 
1 
I 
1 
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UNIT 


INFORMATION MANAGEMENT SYSTEM, DATA COMMUNICATIONS 
(IMS / DC) 

OBJECTIVES: 

AT THE CONCLUSION OF THIS UNIT, THE ATTENDEE SHOULD BE ABLE TO 

1. DESCRIBE THE STRUCTURE OF NETWORK TABLES IN IMS 

2. COMPARE IMS ARCHITECTURE WITH CICS AT A HIGH LEVEL 


IMS-1 




IMS DATA BASE/DATA COMMUNICATIONS 


o PRIMARILY A DATA BASE PACKAGE ✓*** 


' 0 *-£m- -r%. 7 ^ 


o ^DATA COMMUNICATIONS: AS IF AN AFTERTHOUGHT 


o APPROPRIATE WHEN DATA BASE INTEGRITY TAKES 

PRCEDENCE OVER PERFORMANCE AND RESPONSE TIME 


o COMMUNICATIONS NOT AVAILABLE WITH DOS 
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IMS_IERMINAL_SyPPgRT 

(COMMON TYPES) 


o 

IBM 

2260 


o 

IBM 

2740 


o 

IBM 

2741 


o 

IBM 

2780/2770 


o 

IBM 

3270 


o 

IBM 

3600 


o 

IBM 

3614 


o 

IBM 

3630 


o 

IBM 

3767 


o 

IBM 

3770 


o 

IBM 

7770 AUDIO 

RESPONSE UNIT 

o 

IBM 

SYSTEM 3 


o 

IBM 

SYSTEMS 32/34, SERIES 1 

o 

TTY(TWX) 33/35 

DEVICES 
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I_M_S 

iAICH_VS i _gNLINE_PRQCESSING_L)NDER_IMS 


BATCH APPLICATIONS ONLINE SYSTEM 


o SEPARATE PRIVATE/LOCAL 

REGION CONTROLLER FOR EACH 
BATCH APPLICATION 

o EACH BATCH APPL IS AN 
INDEPENDENT JOB 

o OFF LINE, TRADITIONAL, BATCH 
PROCESSING ONLY 


o RUNS UNDER THE CONTROL OF 
SINGLE CONTROL REGION 


o MULTIPLE APPLS (ONE /REGION) 
RUN WITH ONE CONTROL REGION 

o ONLINE ACCESS TO APPLCATIONS 
FROM TERMINALS 

o CAN NOT ACCESS OS FILES 


o THESE WILL NOT BE DISCUSSED 
FURTHER 


NOTE: 


PRIOR TO RELEASE 1.2, BATCH IMS SYSTEMS 
COULD NOT ACCESS ONLINE DATABASES 
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IMS ONLINE CONTROL REGION: INTRODUCTION 



OS / 

l 

i in 

i > 

i i 



A 

A 

A 

CONTROL 

P 

P 

P 


P 

P 

P 

REGION 

L 

L 

L 


1 

D 

4C. 

3 

C R 

M P P 

M P P 

M P P 


IMS CONTROL REGION: 

o CONTAINS IMS SYSTEM ROUTINES, CODE, AND TABLES 

o MANAGES AND CONTROLS THE NETWORK AND ONLINE 
APPLICATIONS 

o PROVIDES ACCESS TO MESSAGE QUEUES FOR ONLINE 

APPLICATIONS AND MANAGES OUTGOING MESSAGES TO 
TERMINALS 

o WORKS INDEPENDENT OF IMS BATCH SYSTEMS 
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IMS ONLINE SYSTEM ORGANIZATION 



OS / VS 

" "" • 

• 

APPLl 

APPL2 

IMS 



CONTROL 



REGION 

• 


o UNLIKE CICS APPLICATIONS (TRANSACTIONS) ARE NOT A PART 
OF THE TP MONITOR JOB 

o NEED INTER-REGIONAL MOVEMENT OF DATA BETWEEN APPLS AND 
IMS 

o ONLINE APPLICATIONS MAY ACCESS ONLY IMS DEFINED 
DATA BASE AND NO OTHER FILES 


‘ v tF jxjSL* ■ i 


L 




JZJfiSL W 
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BATCH PROCESSING WITH ONLINE IMS 


OS / vs 

ONLINE 

APPL 


IMS 



CONTROL 

ONLINE 

APPL 

BATCH 

PROCESSING 

JOB 

REGION 


o BATCH APPLICATIONS CAN ALSO RUN UNDER THE CONTROL OF IMS 
ONLINE CONTROL REGION. 


o SUCH BATCH APPLICATIONS ARE CALLED 'BATCH MESSAGE 
PROCESSING PROGRAMS' OR BMPs 

o ONLINE APPLICATIONS BY CONTRAST ARE CALLED 'MESSAGE 
PROCESSING PROGRAMS’ OR MPPs 

o MPPs ARE AUTOMATICALLY SCHEDULED BY IMS ON ARRIVAL OF 
INPUT MESSAGES. 

BMPs HAVE TO BE STARTED VIA JOB CONTROL LANGUAGE (JCL) 

o IF NEEDED, BMPs CAN ACCESS ONLINE RESOURCES INCLUDING 
MESSAGE QUEUES AND TERMINALS AND ALSO OS FILES 

o BMPs ARE BURDENSOME FOR THE ONLINE PROCESSING AND 
SHOULD BE USED JUDICIOUSLY 
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IMS- 


MESSAGE SCHEDULING 


"THE PROCESS BY WHICH A COMPLETELY RECEIVEO INPUT TRANSACTION 
IS UNITED WITH ITS ASSOCIATED APPLICATION PROGRAM" 

MSG QUEUE PGMLIB 





HOW IS IT DONE? 


IMS USES A 'DOUBLE' ALGORITHM TO SELECT TRANSACTIONS FOR PROCESSING 
CLASS FIRST. THEN PRIORITY WITHIN CLASS. 

MESSAGE CLASS SCHEDULING 

• ASSIGN A CLASS TO EACH TRANSACTION CODE 

• ASSIGN ONE TO FOUR CLASSES TO EACH MESSAGE REGION 

• CAUSE IMS TO SCHEDULE TRANSACTIONS OF A CERTAIN CLASS IN MESSAGE 
REGIONS HAVING A CORRESPONDING CLASS 

PRIORITY 

• ASSIGN A PRIORITY TO EACH TRAN 

0 - LOWEST 
14 - HIGHEST 

• OPTIONAL AUTOMATIC PRIORITY INCREASE WHEN THERE IS A LARGE QUEUE 
BUILOUP 



DiFINING_NEIW0RK_RESQURCES_T0_iMS_ - (.BTA!5) 

QQC3MUNIQAIIQNS.NAME_IABLEI_CNM 

LINEGRP 

LINE 

CTLUNIT 

TERMINAL 

NAME 

TERMINAL 

NAME 

CTLUNIT 

* 0 

m 

m 

m 

LINE 

e 

o 

9 

9 

LINEGRP 

LINE 


MACROS MUST BE CODDED IN THE ORDER SHOWN 
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COMMUNICATION NAME TABLE (CNT): 


Network resource definitions are collectively referred to as the 
Communication Resource Table. Five different macros are used to 
describe the network. 


LINEGRP: One per group of similar lines, macro automatical1y 

generates the BTAM DCB table for the line group. 

LINE: One per line within the group, LINE macro also generates 

the BTAM OECB table for the line. 

CTLUNIT: For BSC3 lines, one per cluster controller, contains, 

among other information, the polling id of the 
controller. 


TEMINAL: One per terminal in the cluster. Contains terminal 

selection id among other information. 

:: per terminal, assigns a symbolic name to 

terminal immediately preceeding the NAME macro. 


NAME: 


the 


Unlike CICS, no DFTRMLST tables are defined for BTAM amd IMS 
bulds them direcltly from the information provided on the CTLUNIT 
and TERMINAL macros. 
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ILLUSTRATIVE OPERANDS FOR IMS/BTAM 


BTAM DEFINITIONS 

ui 

LINEGRP DDNAME=BTAMLNO1,UNITYPE=3270,CODE=EBCDIC 

7 7 pf' 

LINE ADDR=040 A 

CTLUNIT ADDR=40,M0DEL=2 J 

TERMINAL ADDR=40,UNIT=3277,M0DEL=2, 

OPTIONS®(TRANRESP), FEAT®IGNORE . 

NAME LA101AB 1 

TERMINAL ADDR=C1,UNIT=3277, 

OPTIONS®(TRANRESP),FEAT®IGNORE | 

NAME LA102AB 1 

I 
I 
I 
I 
1 
I 
I 
I 
I 
I 
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UNIT 5 


EVOLUTION OF TELEPROCESSING SOFTWARE AND SNA 


QIJEQIIVESL 

UPON COMPLETION OF THIS UNIT, THE ATTENDEE SHOULD BE ABLE TO: 

1. IDENTIFY THE LIMITATIONS OF PRE-SNA ACCESS METHODS AND FRONT 
ENDS. 

2. IDENTIFY THE ROLE AND ADVANTAGES OF TELEPROCESSING MONITORS 
IN A PRE-SNA ENVIRONMENT. 

3. IDENTIFY MAJOR STRUCTURAL AND FUNCTIONAL DIFFERENCES BETWEEN 
BTAM, ACF/VTAM, AND ACF/TCAM. 

4. IDENTIFY MAJOR CAPABILITIES OF EMULATION PROGRAM (EP) . 
PARTITIONED EMULATION PROGRAM (PEP), AND NETWORK CONTROL 
PROGRAM (NCP) AS FRONT END SOFTWARE. 

5. DEFINE THE TERM "COMPUTER NETWORKING" 

6. DESCRIBE THE DIFFERENCE BETWEEN PRIVATE AND SHARED PUBLIC 
NETWORKS. 
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EVOLUTION OF TELEPROCESSING SOFTWARE IN IBM ENVIRONMENT 


BTAM 


SYSTEM 360 


v 



BTAM, 270X, TWX 
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I 


BTAM, 270X, MULTIPLE DEVICES 


270X, MULTIPLE DEVICES, MULTIPLE APPLICATIONS 


BTAM, 370X EP, TELEPROCESSING MONITORS 
(SYSTEM AND APPLICATION SOFTWARE PACKAGES) 


VTAM, TCAM, AND NCP 



ACF PRODUCTS AND NETWORKING 



EARLY SYSTEMS (PRE-MONITORS): 1 







SINGLE APPLICATION SINGLE DEVICE 


TP JOB 
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! IBM 27OX HARDWARE FEP 


SWITCHED 
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CODE TO HANDLE TWX 
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EARLY S YSTEMS -l: Single Application / Single Device 

The very early commercial applications o-f teleprocessing 
technology were o-ften simple systems using low speed 
TTY devices (those were the only ones easily available 
in those days). The physical networks generally used 
switched -facilities as IBM did not support TTY compatible 
devices in a leased line environment. 

These were generally single device single application 
systems with BTAM and the hardware 270X as the 

■front end. 

Application programmer was responsible -for all aspects o-f 
the system and, thus, had to be knowledgeable not only 

in the business -functions but also in BTAM and network 
devices. 

Also, because o-f the limitations imposed by BTAM, the 
software had to be all written in Assembler Language, 
one o-f the more di-f-ficult languages -for writing software. 
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EARLY SYSTEMS (PRE-MONITORS): 


SINGLE APPLICATION 

MULTIPLE DEVICES 


• 

! APPLICATION CODE 

1 

• 

! TWX CODE ! 

1 

3270 CODE 


! BTAM 

CODE 


: 0 

S 


1 

1 

» 

1 

1 


TP JOB 


IBM 270X HARDWARE PEP 


SWITCHED AND PRIVATE LINES 


v ^ X * 
/T 
' / 

r J 
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Earl y System s - 2: Single Application / Multiple Devices 

Basic environment still consisted of BTAM and 270;: with 
assembler still being the primary language. 

With the availabilty of CRT devices (e. g. IBM 3270) that 
could be multi dropped on higher speed private lines it became 
possible to achieve higher performance without a 
disproportionate increase in the facilities cost. 

However, that meant that application programmers had to learn 
multiple protocols and be able to handle various types of line 
connections in their programs. 

Major software changes were needed to support these newer 
devices. Applications became increasingly more complex and 
difficult to maintain and grow. 
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EARLY SYSTEMS (PRE-MONITORS) 


MULTIPLE APPLICATIONS, MULTIPLE DEVICES 


APPL-1 CODE 

l 

APPL-2 CODE 

DEV-1 CODE ! ! DEV-n CODE 

» 

DEV-1 CODE ! i DEV-n CODE 

BTAM CODE 

. . .... _ . . .. .. . 

BTAM CODE 

._ _ .... _ . .. i 

' ' .'. ' ' . ' ...... » 

os : 

i 

i 

i 

i 


• o 

! ! IBM 370X EP 

1 l 

1 t 

i 

NETWORK FOR ! 

APPL-1 : 

NETWORK FOR 
APPL-2 
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Earl y System s - 3: Multiple Applications/Multiple Devices 

As more and more systems were being converted to on-line 
environments, we had all the problems of the earlier 
systems with the additional problem now of a separate 
network for each application - a very expensive proposition. 
From communications point of view, this problem of having a 
de di cated . n etwork for each on-line system was probabaly the most 
serious one and ITS root cause was in the system software itself. 

Also, not only did programming teams for each system need 
advanced level knowledge of data communications, BTAM, and 
business functions, each team was also firmly convinced 
that they had the 'better mouse trap’. 

Thus arose systems in each shop with their own message 
formats, coding conventions, and unique operational 

considerations. 

Result was: Inefficient, expensive networks; 

high software development cost; 
high maintenence overhead; and 
incompatible systems. 
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TELEPROCESSING MONITORS 
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Emergence, o -f^Teleprocessing M onitors: 

With the advent of TP monitors it was now possible to run 
multiple applications in a single partition over a shared 
network. This gave rise to significantly improved 

resource utilization. 

Additional benefits included separation of communications and 
business functions in the software. Communication functions 
were implemented within the monitor and applications 
(transactions) had to handle primarily business functions. 

With most papular monitors it was also possible to write 
application code in high level languages. 

Some of the secondary benefits were: 

o Low cost, low risk entry into teleprocessing, 
o Community of interest and user groups, 
vendor incentive to keep current, 
o Availability of trained personnel 'off the 

street'. 

o Better standardization 

Examples of some of the common TP monitors are CICS,. 
IMS/DC, SHADOW, ENVIRON, and TASKMASTER. 

However, it was not necessary nor desirable to run all 
applications under the control of the TP monitor. But 
applications that ran outside the control of the TP monitor 
still needed separate networks. 

Thus, the problem of dedicated networks was not entirely 
alleviated. Also, first generation TP monitors were not 
capable of allowing network sharing across hosts. 
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EMERGENCE OF NEW ACCESS METHODS 
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PART OF APPL JOB 

INDEPENDENT JOBS 

MUTIPLE COPIES 

ONLY ONE COPY SUFFICIENT 

DEDICATED NETWORK FOR 

EACH ONLINE JOB 

NETWORK SHARED AMONG 

ALL ONLINE JOBS 
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Emergence of new access methods^ 

BTAM, o-f course, is not a new access method and its 
limitations and those o-f systems built around it 
were discussed earlier in this unit. ACF/VTAM 
and ACF/TCAM are the two new access methods that can 
help in getting around some o-f the limitations imposed 
by BTAM based systems. 


ACF/VTAM.and_ACF/TCAM: 

Simifari. ti. esf 

1. Each runs as a s ep arat e O S j ob -from the application programs. 

2. The network is "owned" by the access method and not the 
applications. 

3. Applications sharing the access method can share the 
network. 

4. Both support all major SNA -functions. 

5. Both are very complex. 
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0 EUNQIIQNAL comparison OF IBM ACCESS METHODS 



BTAM 

ACF/VTAM 

ACF/TCAM 

LINK 

PROTOCOLS 

BSC, S/S 

3270 BSC 

SDLC 

• 

BSC, S/S 

SDLC 

FEP 

SOFTWARE 

EP 

NCP 

EF‘, NCP 

DIAGNOSTIC 

CAPABILITIE 

SIMPLE 

EXTENSIVE 

EXTENSIVE 

COMPLEXITY 

SIMPLEST 

VERY COMPLEX 

MOST COMPLEX 

OPERATOR 

COMMANDS 

NONE 

EXTENSIVE 

EXTENSIVE 

M£G O'ING 

/ f >,1 If CjS ft"' 

MSG * 

SWITCHING j, 

V *•■<* rf >7 * • * 

* «»■ C. PtA 

MULTIPLE 

HOSTS 

NONE 

NONE 

YES 

NONE 

NONE 

YES 

NO 

SUPPORT 

YES 

YES 

SNA 

NO 

- YES 

YES 

SYSGEN 

SIMPLEST 

VERY COMPLEX 

MOST COMPLEX 

OP. SYS 
SUPPORT 

OS, DOS 

OS, DOS 

OS ONLY 

“ 7 ^ 

J 2.?0 

p4MaWt» BSC 

ALL MODELS 

ALL MODELS 


SUPPORT 























PARALLEL DEVELOPMENTS 


FEP EVOLUTION: 


HARDWARE FEPs: 


PROGRAMMABLE: 


IBM 270X FAMILY 

IBM 370X FAMILY 

- EMULATION PROGRAM (EP) MODE 

- EP+ MODE (NON-IBM FEPs) 

- NETWORK CONTROL PROGRAM (NCP) MODE 
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Parallei d evelopments: 
Hardware FEPs: 


FEP Evolution 


When 270x-like, non-programmable -front ends -first became 
available, they fulfilled the -following needs: 

a) Provide a standard interface to the host I/O channel on 
behalf of the network. 

b) Partially make up for the speed mis-match between host 
channel and the network. 

c) Provide EIA (or equivalent) interface for each line and 
buffer line data. 

d) Provide some DLC control characters and check for 

transmission errors. 

Some of the major limitations, above and beyond capacity, were: 

Lack of flexibilty, needed vendor personnel to make changes to 
network configuration- expensive for both vendor and the 
customer, and centralization of network management, control, and 
protocols in the host. 

Programmabl e FEP wit h E mu lation Program (.EP)_and_EP+:. 

The advent of solid state technology made possible the creation 
of larger and programmable front ends at a less than prohibitive 
cost. 

Initially, however, these programmable machines did not 
takeover any of the existing host functions as that would 
have required changes in the host system software which most of 
the customers did not want to make. So while programmable, these 
machines still emulated the old hardware FEPs in their functional 
capabilities. Thus, these machines came to be known as Emulation 
Program _(EP2 machines 

Some of the non-IBM front ends not only provided complete EP 
capabilities, but also additional features, such as speed/code 
conversion, not available on IBM3705/EP. Such non-IBM oferrings 
were sometimes also referred to as the EP+ machines. 

Some examples of such vendors are COMTEN (now part of NCR), CCI, 
and Memorex (Burroughs). 

EC.29C£21!I13l£.L£ EEE wi_th Network Control, Program (,NCP )_L 
TVTAM and~TCAM onfy) 

With SNA came the need to off-load network management and control 
functions out of the host and, thus, the NCP. Link protocol 
(SDLC), activation/deactvation of network resources, tracking 
status are done by the front end with NCP. NCP is also capable of 
staying operational even when the owning host is lost- a 
critical requirement in a multiple-host, networking environment. 
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FEP SOFTWARE AND SUBCHANNEL REQUIREMENTS 


E p: 

ONE SUBCHANNEL PER LINE 

ONLY BYTE MULTIPLEXER CHANNEL (SLOWEST) 

N C p: 

ONE SUBCHANNEL FOR THE WHOLE NCP (OR PER CHNL ADAPTER) 
CAN CONNECT WITH BLOCK MUX OR SELECTOR CHANNEL 
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WHAT ABOUT PARTITIONED EMULATION PROGRAM (PEP) 


CURRENT CONFIGURATION: 


ASYNCH, 

BSC 



TRANSITION CONFIGURATION: 


PEP 


EP 


NCR 


ASYNCH 

BSC 


SDLC, 

BSC 3270 


FINAL OBJECTIVE 

VTAM/TCAM NCP 


SDLC 

BSC 3270 
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Early T echnology: R eviewQuic 

1. 
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Identify major 1imi tations/di sadvaptages of teleprocessing 
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Identify major 
environments. 
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3. One o-f the major advantages o-f TP monitors is the ability to 
share the network among multiple applications. What then i 
meant by the "dedicated networks" problem in a TP Monitor 



4. What advantages do programmable -front ends o-f-fer over non¬ 
programmable -front ends even while emulating the non¬ 


programmable -front ends? 





What are the beni -fits o-f NCP over EP? 


6. What is meant by the PEP con-figuration and when is its use 
appropriate? £P 7V~ && 


7. For each o-f the link protocols shown below, identi-fy the 
access methods and front end software with which they can be 
supported: 
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BSC (FULL SUPPORT) 

SDLC 

BSC (3270 ONLY) 
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UNIT 2B 


WHY FORMAL ARCHITECTURES AND SNA 
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EMERGING TRENDS AND ISSUES 
(LATE 60s EARLY 70s! 


"IN THE WORLD OF THE FUTURE, WILL THE INFORMATION SYSTEMS BE 
CENTRALIZED OR DISTRIBUTED, MAXI OR MINI, TOP DOWN OR BOTTOM UP?" 


t 


" YES 


■ i 


DR. LEWIS M. BRANSCOMB 
VICE-PRESIDENT, CHIEF SCIENTIST 
IBM, 1979. 
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The Evolution of the New Issues and Architectures! A lutoriaf 

When discussing teleprocesing or data communications systems 
there are often implied assumptions about what is called a 
network. Obviously, a collection of transmission facilities 
alone without additional protocols is not a network. 

A set of "locally" interconnected terminals (consoles) and 
machines (disks, tapes, printers, etc.) within one computer 
center can be called a network, but are not included in 
teleprocessing discussions since they do not involve 
telecommunications. 

Sometimes networks are classified based upon whether they are 
fixed in place (using leased lines) or transitory (using dial 
up lines). In some cases it is possible to identify a network 
in terms of applications using the network e.g., 
Inquiry/Response, Remote Job Entry, Time Sharing, Data Entry, 
etc. In any significant system a simultaneous mix of several 
of these functions will be found. 

However, one critical characteristic of these systems by which 
they may be distinguished is the manner in which the host 
machine exerts control over the system. In the more 

Tradftfonal. "teleprocessing" or strictly terminal-oriented 

systems, there is only one host and it supports many terminals 
in a hierarchical way. There may be only two levels in the 
hierarchy, host and terminal, or more. A four level hierarchy 
may involve host, front-end, cluster controller, and terminals. 

But in any case, the system control resides i_n ONE host;. 

As the number of single host systems grew, it became desirable 
to consolidate communications networks. There were many 

situations within the same community of users in which 

different hosts (often different types) provided different 
application programs and services to different types of 

terminals over non-shared communication lines often operating 
well below capacity. 

Consolidation of single host networks gave rise to networks 
with multiple coequal hosts, none of which was single-handedly 
in control of the total network. Each of these hosts could 
interact with the other to provide resources to its 

applications and terminals on demand. 





This latter type of environment with multiple hosts is often 
referred to as a "computer networking" or simply "networking" 
environment to distinguish it -from traditional, terminal 
oriented (i.e., single host) systems. 

Once the concept o-f computer networking took hold, it became 
obvious -fairly quickly that advantages o-f such an environment -far 
surpassed the reduction in line costs. Per-forming code 
conversions, providing alternate routing -for backup became 
natural extensions o-f such a system. As viewed by the user 
community (or more accurately, the "potential" user community), a 
networking environment can provide more power-ful options such as 
a complete -freedom -for any terminal to access any CPU or any CPU 
to access any other CPU. 

Such a set o-f general objectives gives rise to a generalized 
de-finition o-f computer networking as "a set of autonomous, 
independent computer systems, interconnected so as to permit 
interactive resource sharing between any pair of end-points." 

However, such a generalized objective of sharing resources raises 
communications issues far more extensive and complex than those 
of achieving increased utilization at a lower cost. 

These issues also involve complex regulatory matters that 
infringe upon the scope of the Bell System's and other regulated 
carriers’ involvement in the networking solutions. 

There is the need for common definitions, message formats and 
protocols between different data-processing systems communicating 
with each other and between data-processing systems and remote 
devices. 

The network management itself presents a whole new set of 
problems. Some of the questions that come up are - which 
operational center is going to be responsible for which part of 
the network? How are the back-ups to be provided? How do 
various hosts coordinate their activities with each other? 

Distribution of data bases is a whole new area which needs a 
separate discussion. There is a great amount of research and 
development effort being spent in this area. The rewards of such 
efforts still seem a few years away. 

So, while networking environments with resource sharing and 
distributed processing have an attractive set of advantages, 
their design and installation is complex enough to put them out 
of the reach of an average potential user today. But, for those 
who do want to explore the implementation of such an environment, 
there are two basic approaches available - Private Networks and 
Shared Public Networks. These two approaches are discussed next. 
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Private N etworks -for C omputer C ommunications 

First of all, a private network in this context does not mean a 
private or leased lines network- switched lines are very much a 
part of it. These networks are private in the sense that they 
are deployed, managed, used, and controlled by a customer for its 
own purposes. The network still consists of predominantly common 
carrier facilities. 

In this context, most existing customer networks today are 
private networks. 

In a networking environment a customer may use an architecture 
such as SNA to build such a private system. In a sense, all that 
SNA would provide in this case would be the guildlines to build 
such a system. 

It would be the customer's responsibility to select appropriate 
SNA compatible terminals, proper hardware and software for the 
front- end, appropriate host system software and applications. 

Customer would also be responsible for physical network design 
(number of private and switched lines, use of satelites, speeds, 
location and number of drops, etc.), modem selection, attaining 
response time objectives, and backup and recovery of network 
failures. 

Somewhere along the way the customer would also have to 
understand what SNA formats and protocols mean, which in itself 
may cause some problems. 


Shared P ublic N etworks,for C omputer C ommunications 

An increasingly attractive option for a number of customers may 
be not to do any development on their own but, rather, connect 
into existing data networks available for public access for a fee. 

Such networks, called the shared public networks, are being 
provided by certain vendors who use common carrier facilities for 
actual transportation of data. Billing to customers is primarily 
based upon usage and not the distance that data has to travel. 

Some other names for such networks are Public Data Networks 
(PDNs) and Value Added Networks (VANs). 

Currently some of the available offerings in the U.S.A. are 
Tymnet from Tymshare, Telenet from GTE and NET/1000 from AT&T 
Information Systems. 

A customer using a public network does not have to worry about 
network management, operation and recovery. Most of these 
networks also provide features (called "values" and, thus, the 
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name VANs) such as code, protocol, and speed conversions which 
make it possible -for an end user to communicate with a diverse 
range of terminals without requiring the support software in the 
host. 

Value added networks, because o-f their complexity, provide a big 
challange to potential vendors. Maintaining security and message 
integrity are two o-f the major concerns o-f the VAN users. But 
on the other hand, VANs also provide ready made data networks 
that one can use with minimal effort in a manner similar to using 
voice networks. While the VAN concept is here along with a few 
basic offerings, it would probably be a few years before VANs 
become an ubiquitous force in the data marketplace. 

It should also be noted that private and public networks are not 
mutually exclusive. It is quite likely that the comprehensive 
solutions of the future would include a combination of both 
public and private networks along with emerging technologies 
such as local area networks (LANs). 
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NEW ISSUES 


MAJOR THEMES HERE ARE: 

DISTRIBUTON OF FUNCTIONS 

RESOURCE SHARING / COMPUTER NETWORKING 

GROWTH: DATA VOLUMES, APPLICATIONS, HOSTS 

MIGRATION: ABILITY TO ACCOMODATE NEW 

TECHNOLOGIES 
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NEW ANSWER: COMPUTER NETWORKING SYSTEMS 


THE PROCESS OF INTERCONNECTING HOST COMPUTERS SO THAT 
THEY CAN COMMUNICATE AUTOMATICALLY 

ANY APPLICATION/TERMINAL IN THE NETWORK SHOULD BE 
ABLE TO ACCESS ANY OTHER APPLICATION/TERMINAL WITHOUT 
ANY REGARD TO ITS LOCATION 

IMPLEMENTATION OF NETWORKING SOLUTIONS THROUGH 
FORMALLY DEFINED ARCHITECTURES SO THAT FUNCTIONS OF 
VARIOUS COMPONENTS ARE PRECISELY DEFINED AND, THUS, 
THERE IS NO AMBIGUITY WITH RESPECT TO COMPATIBILITY 
ISSUES AND FUTURE MIGRATIONS 

SNA IS ONE SPECIFIC EXAMPLE OF THE ABOVE CONCEPT 
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EVOLUTION OF NEW ISSUES AND ARCHITECTURES 


1. As defined in this tutorial, what is the difference between 

a "terminal oriented" and "computer networking" environments" 
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What potential advantage 
networking environment? 
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What are some of the major problems in developin# a 
networking system? S* . > u * r 
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4. What is the major difference between a private network and a 
shared public network ? 
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5. What are some of the problems for a customer considering a 
shared public ne.twork today? 
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UNIT 6 


SNA FUNDAMENTALS 


QiJECIIVESi 

UPON SUCCESSFULLY COMPLETING THIS UNIT THE ATTENDEE SHOULD BE 
ABLE TO DEFINE THE FUNCTION OF: 

NETWORK ADDRESSABLE UNIT (NAU) 

SYSTEM SERVICES CONTROL POINT (SSCP) 

PHYSICAL UNIT (PU) 

SNA SESSIONS 

ACTPU, ACTLU, BIND, AND SDT COMMANDS 
LOGICAL UNIT (LU) 

REQUEST/RESPONSE UNIT (RU) 

REQUEST/RESPONSE HEADER <RH) 

TRANSMISSION HEADER (TH) 

PATH INFORMATION UNIT (PIU) 

DOMAINS 

SUBAREAS 



<T" 
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SNA: INTRODUCTION 


1. .ARCHITECTURE FOR BUILDING COMPLEX MULTIPLE HOST 
NETWORKS WITH DISTRIBUTED PROCESSING AND RESOURCE 
SHARING..." 

2. IBM's ARCHITECTURE 

3. A METHODOLOGY/PHILOSOPHY, A SET OF RULES 

4. ALL IBM COMMUNICATIONS PRODUCTS, HARDWARE AND SOFTWARE, IN 
THE FUTURE WILL CONFORM TO SNA SPECIFICATIONS 


SNA ADDRESSES SELECTED COMMUNICATIONS ISSUES ONLY AND NOT 
APPLICATION ORIENTED FUNCTIONS 


6. CAN IMPLEMENT SNA NETWORKS WITH NON-IBM PRODUCTS SUCH AS 
DATASPEED 4540E, COMTEN, AND AMDAHL AND NUMEROUS OTHER 
VENDORS 







r 


\ 
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WHAT SNA IS NOT 


1. A SPECIFIC PRODUCT - i.e., A PIECE OF HARDWARE/SOFTWARE 

2. A LINK PROTOCOL - IT IS MORE THAN SDLC 

3. A SPECIFIC ACCESS METHOD 

4. A FRONT END 

SNA ENCOMPASSES ALL OF THE ABOVE AND PROVIDES SPECIFIC RULES AND 


PROTOCOLS FOR ALL OF THE ABOVE 




WHAT SNA SPECIFIES 


/ J, 


m 


a -pi** 


l. protocols: 

LINK LEVEL 

FEP TO CLUSTER CONTROLLERS 
FEP TO DEVICES 

§0^ 4 €ea» hsm- 

ACCESS METHODS TO FEP/CONTROLLERS^SfiMHRW^ 
HOST APPLICATION TO DEVICES 


..i ■ 


COMMANDS: 

ACTIVATION/DEACTIVATION 
INTERROGATION ^ 
STATISTICS/DIAGNOSTICS 




CONTROL AND DATA FLOW SEQUENCES 


4. MESSAGE FORMATS: 

HEADERS/USER DATA 
DETAILED BIT SPECIFICATIONS 
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GETTING A HANDLE ON SNA: THREE VIEWS 


OPERATIONAL (STRUCTURAL) VIEW 

- NETWORK ADDRESSABLE UNITS (NAUs), 
SUBAREAS, ... 

LAYERED VIEW 

- SNA LAYERS 

PRODUCT VIEW 


DOMAINS 


VTAM, TCAM, NCP, IBM 3270 






NETWORK ADDRESSABLE UNITS 
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I _ ^ | 

/ ~NAU 


\ NAU 


PRINTER 


SNA-6 













NIIWQ£t< ADDRESSABLE UNIJS JNALJii 

Each network element that can be a source or destination of 
data must have a unique network address and is known as an NAU. 

NAUs include: 

- Host Access Method 

- FEF' Control Program (NCP) 

- Cluster Controllers 

- Terminals 

- Applications 

While communications lines also have SNA network addresses 
associated with them, they are not SNA NAUs since lines cannot 
be the ultimate sources or destinations of messages. 
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JHREE TYPES OF NETWORK ADDRESSABLE UNITS iNAUs) 

SYSTEM SERVICES CONTROL POINT: SSCP 

PHYSICAL UNIT: PU 

LOGICAL UNIT: LU 


HOST 


FEP 


LU 

' 

S 

• ™ *"* * • 

1 1 

1 1 ___ 

: PU !-! !- 

LU 

' 

s 

1 « 

1 1 

1 

l 

< 

t 

c 

1 t 

1 1 

LU 

■' ' 1 

p 

MODEMS 






ACCESS METHOD 


CRT 


CONTROLLER 

1 

1 

l 

.....«*, — 1 

a * 

/ 

LU 

-! PU ! / 



! __ ! \ 

\ 

LU 


I f 

PRINTER 


APPLICATION 














Three types of NAUs defined in SNA: 

SNA -formally de-fines capabilities and functions for its network 
addressable units. There are three types of NAUs defined with 
different capabilities: 

System Services Control Point (SSCP) 

Physical Unit (PU) 

Logical Unit (LU) 

These NAUs will be discussed ne::t. 
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SYSTEM SERVICES CONTROL POINT: SSCP 


OVERALL CONTROL AND MANAGEMENT 


HOST 


FEP 


MODEMS 


A 



s 

s 

c 

p 


! ACF/VTAM 

: or 

APPLICATION ACF/TCAM 



CRT 

m 

CONTROLLER 
.-. / 

- ! ! _ / 

: _ ! \ 

\ 


I ______ I 

PRINTER 
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SYSTEM SERVICES CONTROL POINT (SSCP) 


Special purpose NAU which is used for network management and 
control. 

SSCP resides within the host access method and manages that 
portion of the network that is assigned to this access method. 

Functions of SSCP include 

- Brings up/down the network 

- Helps in setting up sessions 

- Schedules error recovery 

- Executes operator commands 

- Keeps track of the status of network resources. 

While a host access method contains all the SSCP functions, it 
is not limited to the SSCP functions only. An access method, 
typically, also performs functions other than the SSCP. 
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PHYSICAL UNIT: PU 
REGIONAL CONTROL 


CONTAINS A SUBSET OF SSCP CAPABILITIES 
INITIATES ACTIONS BASED UPON COMMANDS FROM SSCP 
PU TYPES: 1, 2, 4, AND 5 


I 

1 


I 


HOST 


CRT 


FEP 


PU 


CONTROLLER 




PU 


/ 

\ 


MODEMS 


PRINTER 


ACCESS METHOD 


APPLICATION 


I 


1 

1 
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PHYSICAL UNIT (PU) 


A PU is an NAU which acts as a companion to the SSCP 
in network management and control -functions- It contains a 
subset o-f the SSCP capabilities. 

Typically, with each PU there is associated a PUCP, Physical 
Unit Control Point. 

Functions o-f a PU include: 

—Activation and deactivation o-f data links (NCP PU) 

-Assistance in recovery procedures during network communication 
■failure (NCP PU) 

-Providing control -functions -for a local operator (cluster 
controller PU) 

-Providing control and management o-f stations directly connected 
to it (cluster controller PU) 

SNA de-fines -four classes o-f PUs: 

TYPE 5 - Host node (PU_T5) 

TYPE 4 - NCP node (PU_T4) 

TYPE 2 - Cluster Controller node (PU_T2) 

TYPE 1 - Cluster Controller node (has less capabilities than 
type 2 PU) (PU_T1) 

It should be noted about the PU_T5 that it is NOT the same as 
the SSCP even though it is contained within the the access 
method. 


SNA-13 





LOGICAL UNIT: LU 


USER DATA 


HOST 


FEP 


MODEMS 

j 

! ACCESS METHOD 



1 1 

1 1 

1 ... _ 1 

1 

LU 

' ' ' ' 1 

i 

1 

1 

1 

| 

1 

1 

1 1 

1 i 

l 1 

LU 

LU 

l 


APPLICATION 
(CICS, TSO,...) 


CRT 

CONTROLLER !_! 

.-. / LU 

: _ / 

! _ : \ 

\ LU 


» I 

PRINTER 
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LOGICAL UNIT 


An LU is an NAU which provides "ports" or "windows" through 
which end-users access the SNA network. 

Typically LUs are associated with devices behind a cluster 
controller and with host applications. 

Functions -for an LU may include: 

-Data conversion for an end-user 
-Local editing 

-Correlating SNA responses with requests 
-Providing Data Flow Control Signals 

-Originating session initiation and termination requests. 
Examples of typical LUs would be: 

Network LUs: CRTs and printers on a controller (such as 4540E or 

4540 ADCCP), each CRT or printer being one LU. 

Host LUs: Online systems such as TSO, IMS, CICS, and JES 

etc. each would constitute one LU. All of CICS, 
with all of its programs, would count as one LU. 
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AN SNA SESSION 


A TEMPORARY LOGICAL CONNECTION BETWEEN 
TWO NAUs 


SESSION MANAGEMENT 

NAU LOCATION 
SESSION AUTHORIZATION 
NAU CAPABILITIES 

DIFFERENT LEVELS OF INTELLIGENCE 
IN DIFFERENT DEVICES 

ARE WE TALKING AT THE SAME LEVEL? 
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SNA Sessions: 


SNA uses the term 'session’ to denote communications between two 
Network Addressable Units (NAUs). A session by definition is a 
temporary logical connection in place by agreement o-f the 
participating NAUs. 

Management o-f sessions is one o-f the major -functions o-f an SNA 
network. In older, pre-SNA, systems such as CICS/BTAM there used 
be only one destination in the host and all sessions belonged to 
it (CICS). 

When there are multiple applications in one host or spread over 
multiple hosts, one o-f the problems is to find the location of 
the application itself. 

Also, it has to be determined if the terminal user is authorized 
to access that host (access method) and its applications. 

Host application LUs are allowed multiple concurrent sessions 
with other LUs. It is important that session data for separate 
sessions be kept separate from each other. 

Different devices in the network have different levels of 
intelligence and capabi1ities. Therefore, one also has to know 
which data formats, SNA commands, and protocols are valid for a 
given device. 

All such issues are part of the session establishment and 
management procedures and are discussed later in this course. 
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HOST 

APPLICATION 


L U 


TYPES OF SESSIONS IN SNA 


ACCESS 

METHOD 


NCP CLUSTER DEVICE 

CONTROLLER 


S 

s 

c 

p 



P u 


LU 


<— SSCP-PU —> 


<-— SSCP-PU 


> 


< 


SSCP-LU 


LU-LU 
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Types of sessions i_Q SNA:. (Single Access Method) 

SNA de-fines the -following classes o-f sessions: 


SSCP - PU 
SSCP - LU 
LU - LU 


Sessions 
Sessions 
Sessions 


Sessions involving SSCP are basically "hand-shake" activities 
that occur when an access method brings up an NCP, cluster 
controller, or a device on a controller. A session with SSCP, 
when established successfully, means that the particular resource 
is "up", available and, usable. 


The session types have a hierarchical relationship, i.e. before 
an LU-LU session can take place, the following sessions must be 
in place in the order shown: 


SSCP 

SSCP 

SSCP 


PU (NCP) Session 

PU (Cluster Controller) Session 
LU (Device) Session 
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LU-LU sessions: INTRODUCTION 


PLU 


SLU 



£. 





PRIMARY 


SECONDARY 


ALWAYS IN HOST 


NETWORK DEVICES ALWAYS 
SECONDARY 


IN TP MONITOR (IF VTAM) HOST SOFTWARE CAN BE 

IN ACCESS METHOD (IF TCAM) SECONDARY WHEN IN SESSION 

WITH ANOTHER PROGRAM 

MULTIPLE CONCURRENT LU-LU ONLY ONE LU-LU SESSION 

SESSIONS PERMISSIBLE ALLOWED AT A TIME 
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LU-LU Sessions Introduction: 


LU-LU sessions are, of course, where all application data is 
carried in SNA. 

There are several additional considerations unique to such 
sessions and some of them are discussed here. 

In an LU-LU session one the LUs must be designated as the Primary 
LU, PLLf, and the other the secondary LU, SLU. Network devices by 
definition are always SLUs. The primary LU has more 

responsibilities in SNA. In an application to application 

session, one of the two applications must act as the secondary 
LU. 

In a VTAM environment, examples of host LUs (PLUs) would be 
subsystems such as CICS, IMS, JES, and TSO. 

In case of TCAM, the host LUs are contained entilrely within 
TCAM. 

While PLUs are allowed to support multiple concurrent sessions 
with several SLUs, an SLU is not permitted to have more than one 
session at any time. 
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SESSION TYPE AND USER INFORMATION LINE 


THE USER INFORMATION LINE (LINE 25) INDICATES THE SESSION STATUS 
OF A 3270 








#1 : 

#2 ! 

#3 I 

#4 ! 

#5 

: #6 


SESSION TYPE 


SYMBOLS ON LINE 25 


SSCP - PU (NCP) 

SSCP - PU (CONTROLLER) 
SSCP - LU 
LU - LU 


BLANK 

BLANK 

SYSTEM 

STICKMAN 


(DURING THE CHANGE-OVER FROM SSCP-LU TO LU-LU, FIELD 1 WOULD 
SHOW “?" FOR A BRIEF DURATION) 


SNA 









OVERVIEW OF SESSION ESTABLISHMENT PROCESS 



(ONLY MAJOR 

DETAILS 

SHOWN) 


HOST 

ACCESS 

NCP 

CONTROLLER 

CRT OR 

APPLICATION 

METHOD 



PRINTER 

1 1 

1 1 

i S 

1 

1 

l 1 1 

1 1 1 

1 

l 

1 1 

1 1 

: s : 

1 

( 

i t 1 

i 1 l 


! L U i 

! C ! 

: pu 

: ! p u : 

! LU 

1 1 

1 1 

1 1 

1 1 

: p : 

i i 

i i 

i 

i 

i 

i 

i i i 

i i i 

i i i 

1 

1 

1 


ACTF'U --> 

< -— + RESP (SSCP-PU SESSION) 

ACTLINK--> 

-+ RESP 

(EXCHANGES ABOVE DO NOT GO BEYOND FEP MODEM) 

********************************************* 

(EXCHANGES BELOW CAN BE SEEN ON THE LINE) 

ACTPU -----> 

<------+ RESP (SSCP-PU SESSION) 

ACTLU ----> 

< -—---—-+ RESP 

(SSCF'-LU SESSION 

<—--------•--- LOGON 

LOGON ACCEPTED -----> 

(LU-LU SESSION) 
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Unit 3: Review Quiz A 





SNA MESSAGE FORMATS AND HEADERS 


HDRS ! MSGS ! HDRS 


PRECISE RULES FOR MESSAGE FORMATS 

DIFFERENT TYPES OF HEADERS CARRY DIFFERENT TYPES 
INTELLIGENCE 

SOME EXAMPLES OF TYPE OF INFORMATION IN HEADERS: 

LINK CONTROL INFORMATION 

ROUTING INFORMATION 

DATA FLOW MANAGEMENT INDICATORS 


OF 


WHETHER THE MESSAGE IS TEXT, SENSE/STATUS INFORMATION 
(e.g., PAPER JAM IN PRINTER), OR SNA COMMAND 





MESSAGE FORMAJS AND HEADERS! REQUEST RESPONSE UNIT,. RU 


i R U 


A 


I 

I 


USER DATA (REQUEST) 

OR 

RESPONSE TO A REQUEST (RESPONSE) 
OR 

SNA COMMAND 


5'EQUESJSi 

OPERATOR ENTERED DATA 

MESSAGES FROM HOST FOR THE DEVICE 


RESPONSES! 

1. SENSE/STATUS INFORMATION: 

INDICATE NON-TRANSMISSION TYPE ERRORS 

EXAMPLES: PAPER JAM, BAD ATTRIBUTES TO CRT 
PROTCOL VIOLATIONS 

2. NULL RU: 

ERROR CONDITION REQUIRES NO FURTHER EXPLANATION 
ANOTHER HEADER CONTAINS GLOBAL RESPONSE 


COMMANDS! 

SNA COMMANDS 

ACTPU, ACTLU, ACTLINK. 

COMMANDS MAY ALSO REQUIRE RESPONSES 
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Message formats and headers^ Request/Response Unit fRUf 

An SNA network not only has the end-user data -flowing through 
it, but also the SNA commands and control in-formation. In any 
case, each entity -flowing through the network is either a 
reguest or a re sp onse. 

Reguestsi All messages that contain user data or SNA commands 
are called "reguests". Thus, the operator entered data at a 
device is a "request" -from the remote device to the host 
application - even though the message may not request the host 
to do anything. Similarily, an application generated message, 
e.g., customer in-formation in response to an operator inquiry, 
is a "reguest" -from application to the remote device. 

In simple English - what have been called messages between end 
users traditional1y - are now called requests. 

Re sp onses: A ^response" is an acknowl edgement -from the 

receiving LU to a "request". Not all requests require 
responses. 

Req ue st /R e sp onse Unit. fRUll An RU is end-user data or 
response or an SNA command be-fore any headers have been 
attached to it. 
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MESSAGE FORMATS AND HEADERS: REQUEST/RESPONSE HEADER (RH) 


! R H ! R U 


A 


A DESCRIPTION OF THE PERSONALITY 
OF THE RU THAT FOLLOWS ME 


WHETHER THE RU IS A: 

REQUEST (USER DATA) 

INDICATORS WHETHER A RESPONSE IS REQUIRED FROM 
RECEIVER- 

DATA FLOW CONTROL BITS 


RESPONSE (SOFTWARE OR DEVICE MICROCODE GENERATED) 
NON-TRANSMISSION ERRORS 

INDICATOR FOR GLOBAL + OR - RESPONSE TO A REQUEST 

OR SNA COMMAND 

IF - RESPONSE, RU MAY HAVE SENSE/STATUS INFO 
SNA COMMANDS 

ACTPU, ACTLU. BIND, . 

MORE COMPREHENSIVE LIST LATER 
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Message formats and headersj_ Reguest/Resgonse Header fRH1 


Re qu est/Response Header fRHii An RH is added to each RU to 
indicate whether: 

RU is a request or response (and the actual Response type, 
i-f response) 

RU contains control in-formation and the category o-f 
control in-formation. 


Combination o-f RH and RU is also called the Basic In-formation 
Unit or BIU. 
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MESSGAE FORMATS AND HEADERS: TRANSMISSION HEADER <TH> 


< 


PIU 


> 


! T H ! R H ! R U 


ROUTING INFO 


MESSAGE ORIGINATION AND DESTINATION ADDRESSES 


OTHER INFORMATION TO BE DISCUSSED LATER 


PATH INFORMATION UNIX jPIUi 

TH + RH + RU COMBINATION IS REFERRED TO AS THE 
INFORMATION UNIT <PIU> IN SNA 


PATH 
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Message formats and headers! Transmission Header jtJHi 


Transmission Header iJHi! A TH is added to RH by Path Control. 

TH contains the address o-f the message origin and destination 
points and indicates the type o-f PU the message is destined 
■for. 

The combination o-f TH, RH, and RU is called the Path 
Information Unit, PijJ. 
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MESSAGE FORMATS AND HEADERS: SDLC HEADER AND TRAILER 


<- PIU 


* • 

i SDLC HDR ! T H I R H ! R U ! SDLC TRLR ! 

I I 

1 ^ _ ____ ^ 1 

” “ / 

\ / 

\ / 

\ / 

\ / 

\ / 


SDLC 

HEADER AND TRAILER 


LINK MANAGEMENT INFORMATION 

PARITY INFORMATION FOR DETERMINING LINK ERRORS 


PIU PART OFTEN SHOWN 
AS "USER DATA" IN SDLC 
DOCUMENTATION 
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TRANSMISSION HEADER! INJRQDLICTJON 


SNA ALLOWS MULTIPLE TYPES OF TRANSMISSION HEADERS 
EACH TH IS IDENTIFIED BY ITS FORMAT ID (FID) 


BYTE 0 


TH OVERVIEW 


OTHER INFORMATION 


10123145671 
BITS 0-3 BITS 4-7 

I I 

I I 

! v 

! IGNORE FOR NOW 

I 

I 

I 

I 

V 

FID TYPE 

USED WITH NETWORK STATIONS: 


ROUTING AND OTHER 
INFORMATION 


0010 

FID2 

6 BYTES 

USED 

WITH 

PU. T2 

0011 

FID3 

2 BYTES 

USED 

WITH 

PU. T1 


USED 

INTERNALLY 

BETWEEN 

NCPs AND HOSTS: 

0000 

FIDO 

10 

BYTES 

HOST—NCP, NCP-NCP, FOR NON-SNA DATA 

0001 

FID1 

10 

BYTES 

HOST—NCP, NCP-NCP 

0100 

FID4 

26 

BYTES 

REPLACES FID 1 AS OF RELSE 3 

1111 

FIDF 

26 

BYTES 

INTERNAL TO SYSTEM, RELSE 3 


NOTE: VTAM DOES NOT SUPPORT FID O 








FID USAGE REVIEW 


CICS 


VTAM 


I 

I 


NCP 


PU.T2 


LUA ! !—! 


PU.T1 


LUC 


PU.T2 


! LUB 


FOR THE CONFIGURATION SHOWN ABOVE, SHOW TH FID TYPE FOR MESSAGES 
FOR EACH OF THE LINKS. ASSUME PRE-RELEASE 3 SOFTWARE, NO FIDs 
4 IN USE. 
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SNA HEADERS AND HOST COMPONENTS 


HEADER/DATA HOST COMPONENT RESPONSIBLE 


R U 

APPL 

TP MONITOR 

ACCESS METHOD 

* 

R H 

ACCESS METHOD 

T H 

ACCESS METHOD 

(NCP) 

S D L C 

NCR 


* EVEN THOUGH APPLICATION AND TP MONITOR MAY SPECIFY THEIR 
REQUIREMENTS FOR RH, THEIR REQUIREMENTS ARE FASSED TO THE 
ACCESS METHOD AND THE ACTUAL RH IS ALWAYS BUILT BY THE 
ACCESS METHOD 
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DOMAINS AND SUBAREAS 


DOMA X IM 



SUBAREA 
HOST SSCP 




! NCR 


! NCR 
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Domains and Subareas: 


For the purposes of controlling resources (FEPs, links, PUs, and 
LUs> and routing messages through an SNA network, all resources 
are viewd as belonging to domains and subareas. 

Domains: Each SSCP in an SNA network is assigned the ownership 

of a part o-f the network. All resources that belong to the same 
SSCP constitute the domain o-f that SSCP. 

Only the owning SSCP can activate or deactivate a resource. 

Subarae: The concept o-f subarea exists strictly for providing 

route definitions and not for control purposes. 

Each SSCP and NCP must be assigned a unique number, called the 
subarea number during the sysgen. Subarea numbers have to be 
unique not only within the domain but also across domains in 
multiple host environments in order to ensure unambiguous paths 
through the network. 







SUBAREA NUMBERj. NETWORK ADDRESS* AND TH 


SNA NETWORK ADDRESS: 

<-16 BITS (2 BYTES) -> 

• tm “ mm — .riiiiin ”1 i mu " r~ mmmmrn I " i ' MB ~ '‘* a ° # 

i SUBAREA ! ELEMENT 

i BOUNDARY FIXED BY SYSTEM PROGRAMMER 


NETWORK ADDRESS AND TH: FID 1 AS AN EXAMPLE 


BYTE 

0 


FID 1 

3 4 5 6 7 8 9 


D A F ! OAF 


I I 

v !___ SUBAREA/ELEMENT OF MSG 

.-—---■. DESTINATION AND ORIGIN 

10123145671 DAF: DEST ADDRESS FIELD 

BITS 0-3 BITS 4-7 OAF: ORIG ADDRESS FIELD 


IGNORE FOR NOW 


v 

FID TYPE 
0001 FID1 
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SUBAREA NUMBER* NETWORK ADDRESS* AND TH 


As mentioned earlier, subarea numbers are used to generate 
network addresses -for the network resources (NAUs) . All NAUs 
connected to the same subarea have a common subarea address and 
each resource has a unique element number within the subarea. 

The network addresses in SNA are 2 bytes (16 bits) long. The 
■first (le-ft) part o-f the address contains the subarea number and 
the second part contains the element number. 

SNA does not require any particular boundary between subarea and 
element parts. It is the responsibility of the system programmer 
to speci-fy the subarea/element boundary as a part o-f the system 
generation procedures. 

The network addresses are ultimately plugged into the 
Transmission Header (TH) and are used as a basis -for routing 
messages through the network. 

Example on the opposing page shows a FID 1 TH and the locations o-f 
message origination and destination addresses within the TH. 

Other TH types will be discussed in more detail later in the 
course. 




Unit 3: Review Quiz 2 


1. What i s the purpose of TH? 


Which host software component provides the TH? 


3. What type of information is carried in an RH? (give any 
three examples) 


4. 

5. 

6 . 


What is an SNA domain? 

What are subarea numbers associated with in an SNA network? 

For the PIU shown below, answer the questions below: 


. I | 

L^obooopooojooo 


50008 088000010201C002 


(PIU is host to NCP, the system is generated to accomomodate 
no more than 15 subareas) 


a) What FID type TH is being transmitted? 

b) What is the subarea number of the host? 

c) What is the subarea number of the NCP? 

d) How many bytes are contained in the RH/RU part of the PIU? 

e) Does the RU contain an SNA command or user data? If SNA 
command, which one? 

7. 1F00060E020000010006 6B8000 110101 

For the PIU above, indicate the following: 

TH FID type: 

RU is: Request or Response 

RU contains: Data or SNA command 

If SNA command, name of the command: 
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UNIT 7 


HIGHER LEVEL SNA PROTOCOLS - I 


OBJICIIVESi 

AT THE CONCLUSION OF THIS UNIT, THE ATTENDEE SHOULD BE ABLE 
DEFINE THE MEANING AND APPLICATION OF THE FOLLOWING 
PROTOCOLS: 


SEGMENTATION 

CHAINING 

PACING / VPACING 
SEQUENCE NUMBERS 


TO 

SNA 
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NEED FDR HIGHER LEVEL PROTOCOLS 


ONLINE 

ACCESS 



CLUSTER 

PRINTER 

APPL SYS 

METHOD 

FEP 


CONTROLLER 

OR CRT 

■ • 

1 t 

1 ( 

i lu : 

i t 

i i 

■ 

1 

1 

-! SSCP 

1 

I 

• • • 

!-: PU ! 

1 1 1 

i 1 i 

” 7 

& - 

• • 

1 1 

1 1 

-! PU !—— 

1 » 

i 1 

• ■ 

1 1 

i 1 

! LU : 

1 1 

1 1 

25K 

250K 

100K 


0.2K 

IK 


FINITE AMOUNT OF STORAGE IN: 

VTAM BUFFERS 
NCP BUFFERS 
DEVICE PU BUFFER 
STATION CLUSTER BUFFER 


NEED TO GUARD AGAINST SENDING MORE DATA THAN CAN BE HANDLED 
BY A GIVEN ENTITY: 

SHOULD THE MESSAGE BE DIVIDED IN TO SMALLER PIECES? 

HOW BIG SHOULD BE THE "PIECES"? 

GIVEN PROPER SIZED "PIECES", CAN WE RELEASE THEM ALL 
AT THE SAME TIME? 


ASSUMING A SYSTEM TO BE CONFIGURED AS ABOVE. HOW SHOULD AN 
AF'LLICATION GENERATED 2K LONG MESSAGE BE HANDLED? 
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SNA PROTOCOLS TO PREVENT FLOODING OF BUFFERS 


ONLINE 

ACCESS 




AF'PL SYS 

METHOD 

FEP 


CONTROLLER 

1 1 

1 ( 

! LU I 

• ■ ■ 

1 1 t 

i • l 

- ! SSCP ! - ! 

* _««.««« 

PU ! 

7 

• ■ 

1 1 

1 1 

- ! pu : - 


SOME OF THE PROTOCOLS UNDER SNA THAT HELP IN MANAGING THE 
DATA WITHOUT EXCEEDING / FLOODING VARIOUS BUFFERS: 


SEGMENTATION: 

CHAINING: 

SEQUENCE 

NUMBERS: 

PACING: 

VPACING: 


CONTROLLER (PU) BUFFERS 
PRINTER/CRT (LU) BUFFERS 
TO RECOVER CHAINS 

PRINTER/CRT (LU) BUFFERS 
NCP / VTAM BUFFERS 


NOTE: NOT ALL DEVICES SUPPORT ALL OF THE ABOVE 


PRINTER 
OR CRT 


LU 


FLOW OF 
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SEGMENTATION 


"TO ENSURE THAT NO SINGLE PIU EXCEEDS THE PHYSICAL UNIT (Pin 
BUFFER " 


PLU 


AM 



SLU 


N C P 


P U 


SEGMENTATION 


1. USED BETWEEN NCP AND PU (A PU-PU PROTOCOL) 

2. ANY PIU THAT EXCEEDS THE PU BUFFER SIZE WILL BE "SEGMENTED" 
INTO MULTIPLE PIUs BY THE NCP 

3. FOR EACH PU IN THE NETWORK, ITS BUFFER SIZE IS SPECIFIED 
DURING THE NCP SYSGEN 


PIU 


TH ! RH ! RU 


SEGMENTATION INDICATORS ARE CARRIED 
IN THE TRANSMISSION HEADER 
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CHAINING 


"TO ENSURE THAT NO SINGLE PIU EXCEEDS THE LOGICAL UNIT UJJ) 
BUFFER" 

A M FEP P U 

■ ■ a ■ ■ m 

I I I I I I 

I I I I — — — ( , 


CHAINING 

1. USED BETWEEN PLU AND SLU. (AN LU-LU PROTOCOL) 

2. ANY PIU THAT EXCEEDS THE RECEIVING LU’s BUFFER MAY BE CHAINED 
INTO MULTIPLE ELEMENTS BY THE SENDING LU 

3. FOR CHAINING, THE SENDING LU MUST KNOW THE SIZE OF THE 
RECEIVING LU’s BUFFER SIZE 

4. EVEN THOUGH USED WITH IBM CRTs ALSO, PRIMARILY USEFUL WITH 
LONG REPORTS FOR PRINTERS 


APPL 



PLU 


PRINTER (CRT) 


SLU 


PIU 


TH 


RH 


RU 


CHAINING INDICATORS ARE CARRIED 
IN THE REQUEST/RESPONSE HEADER 
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SEQUENCE NUMBERS 


"TO KEEP TRACK OF CHAINS AND CHAIN-ELEMENTS IN AN LU-LU SESSION" 


PRINTER (CRT) 


A M FEP 


P U 



P L U 


S L U 


SEQUENCE NUMBERS 


1. ALL F'lUs IN A SESSION ARE ASSIGNED SEQUENCE NUMBERS, EACH 
NEW PIU BEING ONE HIGHER THAN THE PREVIOUS ONE 

2. SEQUENCE NUMBERS ARE USED FOR RECOVERY PURPOSES 

3. WHEN CHAINING IS IN USE, EACH ELEMENT IN A CHAIN IS ASSIGNED 
A NEW SEQUENCE NUMBER 


PIU 


TH ! RH ! RU 


SEQUENCE NUMBERS ARE CARRIED 
IN THE TRANSMISSION HEADER 
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PACING 


"TO LIMIT THE MAXIMUM NUMBER OF PIUs RELEASED TO A SPECIFIC LU AT 
ANY GIVEN TIME SO THAT THE LU BUFFER IS NOT EXCEEDED" 


PLU 



PRINTER (CRT) 


PU 



N C P 


S L U 


PACING 


1. USED BETWEEN NCP AND SLU (NCF'-LU PROTOCOL) 

2. SPECIFIED AS A NUMBER, e.g., PACING*=n. AND NCP WILL NOT SEND 
MORE THAN "n" PIUs TO THIS LU. NCP WILL THEN REQUEST AND 
WAIT FOR A "PACING RESPONSE" FROM THE LU. 

NCP WILL SEND "n" MORE PIUs AFTER RECEIVING THE PACING 
RESPONSE 

PACING COUNTS FOR EACH LU ARE SPECIFIED DURING THE NCP 
SYSGEN 

3. IF CHAINING IS IN USE, EACH CHAIN ELEMENT IS COUNTED AS A 
PIU FOR PACING. SEGMENTS ARE NOT COUNTED 

4. VERY USEFUL PROTOCOL FOR PRINTERS 


PIU 


TH ! RH ! RU 


PACING INDICATORS ARE CARRIED 
IN THE REQUEST/RESPONSE HEADER 
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SEGMENTATION VS CHAINING 


SEGMENTATION 


CHAINING 


BASED UPON PU BUFFER SIZE 


DONE BV THE NCP OR CONTROLLER 
(PU) 


HAS NO EFFECT ON SEQUENCE 
NUMBERS 


SEGMENTS DO NOT COUNT TOWARDS 
PACING 


BASED UPON LU BUFFER SIZE 


DONE BY APPLICATION OR DEVICE 
(LU) 


CAUSES SEQUENCE NUMBERS TO BE 
INCREMENTED 


EACH CHAIN ELEMENT IS COUNTED 
TOWARDS PACING 
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exercise: chaining, segmenting, pacing, and 

SEQUENCE NUMBERS 


GIVEN! CLUSTER <PU> BUFFER = 256 BYTE 
PRINTER (SLU) BUFFER* 2K 

AN APPLICATION PROGRAM HAS THREE REPORTS FOR THIS PRINTER, 
MONTHLY, WEEKLY, AND DAILY CUSTOMER TROUBLE REPORTS. 

EACH REPORT = 4 PAGES, EACH PAGE = IK 

EACH REPORT IS TO BE TRANSMITTED AS A SEPARATE CHAIN AND EACH 
PAGE IS A SEPARATE ELEMENT IN THE CHAIN. 

i.e., THREE CHAINS, 4 ELEMENTS EACH, EACH ELEMENT = 1 K 

TOTAL DATA = 12 K 

LAST SEQUENCE NUMBER USED = 1000 


CHAIN 3 


CHAIN 2 


! yfCi jffc« jj 


! HV, MC: 


CHAIN 1 


HOST ACCESS SLU 

LU METHOD FEP PU (PRINTER) 




—,___> 12 k- 


250 2K 

BYTES 


WHAT SHOULD THE NCP DO 




!4 U 


RECOMMEND A PACING COUNT. , 

SHOW ALL INSTANCES OF SEGMENTATION. 

SHOW THE FINAL SEQUENCE NUMBER FOR THE REPORTS.' 


2 J< 


H 
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VPACING 


"TO PREVENT FLOODING OF NCP BUFFERS WHEN NCP IS RECEIVING PIUs 
FROM THE HOST FASTER THAN IT CAN RELEASE THEM TO THE NETWORK" 


HOST 


ACCESS 



SLU 

LU 

«fj». 

METHOD 

FEP 

PU 

(PRINTER) 



• m 

m • 

• 

• • ■ 


✓ 


VPACING-—> 


1. USED BETWEEN VTAM AND NCP. (SSCP-PU PROTOCOL) 

(CAN ALSO BE USED BETWEEN VTAM AND PLU) 

2. NCP MAY NOT BE ABLE TO RELEASE PIUs AS FAST AS IT RECEIVES 
THEM DUE TO SLOWER DEVICES OR PACING, AND MAY RUN OUT OF 
OR LOW ON BUFFERS 

3. BY SPECIFYING VPACING, CAN LIMIT THE NUMBER OF PIUs THAT 
VTAM RELEASE TO NCP AT ANY GIVEN TIME FOR A GIVEN LU 

4. VPACING VALUE TO VTAM FOR AN LU IS, GENERALLY, SPECIFIED THE 
SAME AS THE PACING VALUE FOR THAT LU TO THE NCP 

5. USEFUL WITH PRINTERS 
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HIGHER level PROTOCOLS*. LLj-LLJ SESSIONS AND BIND IMAGE 


SESSION PARTNERS MUST AGREE UPON THE HIGHER LEVEL PROTOCOLS 
TO BE USED DURING THE SESSION 

PROTOCOLS SUPPORTED BV REMOTE DEVICES DEFINED IN THE HOST 
DURIN THE SYSGEN BASED UPON DEVICE SPECIFICATIONS AND ARE 
CALLED THE BIND IMAGE OF THE DEVICE 



/ G^ 

,4M % 


xyz: 


J 



24 X 80 CRT, 
CHAINING OK, 

NO PACING, 

CAN LEAP OVER TALL. 


I WANT TO TALK 
TO PU X. MY 
BIND IMAGE NAME 
IS XYZ 
(LOGON MSG) 
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CONSIDERATIONS FOR IBM 3270 


IBM 3270 SUPPORTS ALL OF THE FOLLOWING: 

SEGMENTATION 

CHAINING 

PACING 

SEQUENCE NUMBERS 


SEGMENTATION CONSIDERATIONS FOR PLL 

PU BUFFER SIZE MUST BE SPECIFIED ■ 265 

NCP WILL SEGMENT ALL PIUs (TH+RH+RU) > 265 BYTES 

3270 CONTROLLER WILL ALSO SEGMENT PIUs >' 265 BYTES 


CHAINING CONSIDERATIONS FOR 3270: 


HOST MAY CHAIN ELEMENTS TO ANY SIZE LESS THAN 2048 

3270 DEVICES CAN CHAIN AT 1024 (SOME COMPATIBLES CAN GO UPTO 
2048), BIND IMAGE TELLS THE DEVICES WHICH S*ZE TO USE. 


PACING CONSIDERATIONS: 


CRTs: NO PACING RESTRICTIONS FOR CRTs, FROM A PRACTICAL POINT 

OF VIEW, THERE SHOULD BE NO NEED TO PACE THE CRTs. 

PRINTERS: 

LU TYPE3: DO NOT SUPPORT PACING, NONE IS NEEDED SINCE THEY 
SUPPORT SINGLE ELEMENT CHAINS WITH DEFINITE RESPONSE 

LU TYPE1: COMPUTE PACING VALUE ASSUMING PRINTER BUFFER ABOUT 3K, 
i.e., DO NOT RELEASE PIUs COLLECTIVELY LARGER THAN 3K 
AT ANY TIME. 
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Unit 5: Review Quiz 


1. Which SNA protocol(s) can be used to help prevent messages 
■from exceeding the: 


a) LU buffers 


b) PU buffers 

What are the similarities and differences between chaining 
and segmentation?. 

Si mi 1 ar i ti es: 


Differences: 


What are the similarities and differences between Pacing and 
Vpacing? 

Similari ties: 


Differences: 


4. Among the Application, the Access Method, and the NCP, who 
is responsible for each of the protocols shown below? 

Pacing: 

Chaining: 

Segmentation: 

Vpacing: 
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UNIX 17 


PU AND LU TYPES FOR NETWORK STATIONS 
OBJECTIVES! 

AT THE CONCLUSION OF THIS UNIT, THE ATTENDEE SHOULD BE ABLE TO: 

1. DESCRIBE THE DIFFERENCE BETWEEN PUs TYPE 1 AND 2 

2. IDENTIFY THE TRANSMISSION HEADER (TH) TYPES USED WITH 
DIFFERENT PU TYPES 

3. DEFINE THE TERMS FM AND TS PROFILES AS THEY RELATE TO 
DIFFERENT LU TYPES 

4. DESCRIBE THE LAYOUT OF THE BIND IMAGE 
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MAPPING_DEVICE CHARACTERISIICS_INTO 
SNA PROTOCOLS 
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MafiEinS Devi.ce Characteristics into SNA Protocols 

SNA de-fines a very large set of functions for remote 
devices. However, not all functions are required nor 
necessary for all devices. For each device in an SNA 
network there must be identified a set of SN A functions that 
the device is capable of performing. 

To provide a systematic methodology for specifying a 
potentially very large number of permutations and 

combinations, SNA defines classes of PUs and LUs. Each 
SNA device must conform to capabilities defined in these 
classes to be a proper SNA device. 

A PU or LU type is, in effect, a grouping of logically 
compatible functions. 


Physical U nits: 

For network devices two types of PUs are defined, types 
1 and 2. Besides the degree of 'SNA intelligence’, the 

major difference occurs in the way Transmission Header 

(TH) is built and the way Path Control sends information 

to the PU. 

Logical .Units: 

SNA defines 7 types of LUs: 0, 1, 2, 3, 4, 6, and 7. Each 

LU type represents a set of LU-LU protocols that are 
supported by that LU. 

Note that there is no type 5 Logical Unit. 

The capabilities and restrictions associated with a 
given type of Logical Unit pertain to functions 

associated with the following layers: 

Function Management Data Services, Data Flow Control, and 
Transmission Control. 

Each class supports a different subset of the above layers. 


PU/LU 
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£§VICE AND PU TYPE 

o PU TYPE 2 HAS MORE CAPABILITIES 
USES FID 2 TH 



NOIESi 

1. PU TYPE DETERMINES THE TYPE OF TH TO BE USED IN 

COMMUNICATIONS WITH A GIVEN DEVICE 

2. IBM DOES NOT PROVIDE ANY FORMAL DEFINITION OF 

DIFFERENCES BETWEEN TYPE 1 AND TYPE 2 PUs WITH THE 

EXCEPTION OF THE TH FORMAT 

3. NOT ALL DEVICES WITHIN THE SAME PU CLASS NEED HAVE THE 

SAME SET OF SNA CAPABILITIES. IMPORTANT TO KNOW 

PRECISE TECHNICAL SPECIFICATIONS OF THE DEVICE 
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ADDRESSING NETWORK COMPONENTS AND TH 


o PROPER SNA ADDRESS 

SUBAREA / ELEMENT FORMAT 

USED IN FID 1 THs, FID 4 THs ALSO CONTAIN THE 
NETWORK ADDRESS BUT IN AN EXPANDED FORMAT 


o 


LU 


LOCAL ADDRESS 

1 BYTE HEX ID OF THE CRT/PRINTER 
CLUSTER 

USED IN FID 2 AND FID 3 THs 




WITHIN THE 


o PU ADDRESS 

1 BYTE HEX ID OF THE CLUSTER CONTROLLER 
USED IN SDLC HEADER AND NOJ IN ANY OF THs 


(LINES ARE ALSO ASSIGNED ADDRESSES INTERNALLY BY THE NCP) 
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Addressing N etwork Components a nd T H: 


There are several forms of addresses that are used in 

an SNA network. Some of these addresses are specified in 
the TH and, therefore, affect the size of the TH. 

Various types of addresses are: 


NAU Network Address: 


This is 
long and 
discussed 
computed 
addresses 


the 'proper' SNA resource ID. It is two bytes 
consists of subarea and element components as 
earlier in this course. These addresse are 
during the NCP system generation. All network 
must be unique across the SNA network. 


FIDO and FID1 


THs use this form of addressing. 


LU Local address: 


This is a 1 byte address that is assigned to each LU 
behind a F'U. These are generally assigned in a 

sequential order, 1, 2, 3,... etc. Each LU on a F'U must 
have a unique local address. LU local addresses are 

specified during the NCP system generation and are 
generally hardwired within the LU. 

FID 2 THs use this form addressing which in turn are used with 
LUs (CRTs and printers) connected to a F'U. T2 control 1 er. 

FID3 THs use siight1y modified form of this address which 
in turn are used with LUs (CRTs and pri nters) on a F'U.Tl. 

Py„Address: 

This is a 1 byte device ID that is hardwired in 

each PU. This address is used in the SDLC header as 

the destination address and has no effect on the TH. 

Line Address: 

Each line in the network is assigned a unique network 
address by the NCP. Line addressing has no effect on 
the TH. 
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TH REVIEW FOR F'U.Tl AND PU.T2 



jL» 


L- ^ 


4 ^ 


o 


FID2: 

1 


/ 


/ 


FOR PU.T2, 6 BYTES LONG 
3 4 5 


DAF ! 


OAF' 


3NF 




y 


0 


FID 3 = 

1 


F'U.Tl, 2 BYTES LONG 


I DAF ! 


ONLY 6 BITS USED FOR ADDRESSIN6 



EFI: Q=NQRMAL FLOW, 

1 =EXF'ED I TED FLOW 


FID2: 0010 
FID3: 0011 


;-> NOT USED 

-> SEGMENTATION: 00=MIDDLE, 01=LAST 

10=FIRST, 11=ONLY 


DAF’: BEST LU ID (PU ID IS IN SDLC HDR) 

OAF’: ORIB ADDRESS FIELD, DOES NOT CONTAIN ANY ADDRESS 

SNF: SES. NUHBR FIELD 

EFI: EXPEDITED FLON INDICATOR 
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DEVICE CAPABILITIES AND LU TYPE 


/ 4 ^' ] 


s - 





LU CATEGORIES BASED UPON FM (FMDS AND DFC) AND TC SUBSETS 
IMPLEMENTED IN A DEVICE 


CAPABILITIES PROFILES 


TWO TYPES OF PROFILES FOR EACH LU: 

FM PROFILE NUMBER 

DEVICE CAPABILITIES AS PER FMDS AND DFC LAYERS 
TS PROFILE NUMBER 

DEVICE CAPABILITIES AS PER TC LAYER 
IBM DEFINED PROFILE NUMBERS, EACH REPRESENTING IBM 
SELECTED SET OF CAPABILITIES 


PROFILES OF EACH UNIQUE LU PROVIDED TO THE HOST ACCESS 
METHOD (SSCP) DURING SYSGEN 

BIND IMAGE TABLE 
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Secondary Logical Units are assigned classes depending upon 
their capabilities with respect to Function Management Data 
Services (FMDS), Data Flow Control (DFC). and Transmission 
Control (TC> Layers. 

There are two types of pro-files defined for each class of LU: 

Function Management _(FM_)_ F'rof iJLei This profile defines the 

LU capabilities associated with FMDS and DFC layers. 
Currently 9 types of FM profiles are defined in SNA. 

Transmission Services J.TS2 Profiie^ (Formerly known as 
Transmission Subsystem Profile). 

This profile defines the LU capabilities associated with 
the TC Layer. Currently SNA defines 7 types of TS 
profi1es. 

These profile numbers are IBM defined and each number represents 
an IBM defined set of capabi1ities. The end user cannot create 
new profile numbers. 

Since IBM defined profile numbers are not very precise in what 
they represent, the end user is allowed to qualify the profile 
numbers through additional statements. 

Bind _Image^ The FM profile, TS profile and the qualifiers for 
a device are called its Bind Image and are described in a table 
called the Bind Image Table. Bind images are defined as a part 
of the access method system generation. As many Bind images may 
be defined in the system as is appropriate. Alike LUs may use 
the same Bind image. 


F‘U/LU-11 




1 

rr 

ii 

1 

1 

I 

I 

1 

I 

I 

I 

I 

1 

1 

I 

I 

I 
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PROFILES FOR SOME COMMONLY KNOWN DEVICES 
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WHERE ARE LU PROTOCOLS KEPT IN THE ACCESS METHOD 


ACCESS METHOD LOGON MODE 

TABLE 

ENTRY 1 
ENTRY 2 


ENTRY n 





LOG MODE 
ENTRY 


ENTRY n 

FM PROFILE # 
TS PROFILE # 

+ 

QUALIFIERS 


LOGON MODE TABLE LOGMODE CONTENTS OF 

OR OR AN ENTRY 

LOGOMODE TABLE BIND IMAGE 

OR ENTRIES 

BIND IMAGE TABLE 

ONE/UNIQUE LU 


PU/LU-14 
















LU Protocols and Access Method: 


One of the important tables coded as a part of the access method 
system generation is the so called Logon Mode T able (or the Bind 
Image Table). 

This table defines the session protocols supported by each LU in 
the SNA network. These protocol definitions are called the Bind 
images. There must be a bind image defined for each LU in the 
system. Similar devices (e.g., 3270 and all its non-IBM 
compatibles) can use the same bind image. 

Each bind image in the table is assigned a unique name and this 
name must be provided to the SSCP as a part of the logon (LU-LU 
session) establishment procedures. 

IBM provides a standard bind image table with each access method 
and it contains bind images for most IBM devices. The IBM 
provided table can be replaced or modified by the customer to 
meet customer's specific needs. 
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A TYPICAL BIND IMAGE (IBM 3270) 


BYTE # 


CONTENTS 


o 


6,7 

8 

9 

10 
11 

12. 13 
14 

15-19 
20,23 
24 


X '31 ’ BIND COMMAND 

RESERVED 

X'03' FM PROFILE 

X '03* TS PROFILE 


PROFILES 


X 'B1 ’ 

X '90” 

X '3080'. 

n 




QUALIFIERS 


PRIMARY PROTOCOL 
SECONDARY PROTOCOL SjL(J 
COMMON PROTOCOLS 
3270-HOST PACING COUNT 
n HOST-3270 PACING COUNT 

MAX. RU SIZE FROM 3270, CHAINING CRITERINON FOR SLU 
MAX. RU SIZE FROM HOST, CHAINING CRITERION FO HOST 
NOT APPLICABLE 

DATA STREAM TYPE X'Ol’-LUl, X'02’-LU2, X'03’-LU3 

NOT APPLICABLE 

SCREEN/BUFFER SIZE, LU TYPES 2 V. 3, USED IN CONJUNCTION 

WITH BYTE 24 

SCREEN/BUFFER SIZE 
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DESCRIPTION OF BIND IMAGE FIELDS 


Si'll 21 FM PROFILE - X '03 7 

PLU/SLU USE DELAYED CONTROL MODE 
PLU/SLU USE IMMEDIATE RESPONSE MODE 


iHE3l TS PROFILE - X'03’ 

PACING ALLOWED BOTH WAYS SEQ #s ALLOWED CLEAR, SDT REQUIRED 
RQR, STSN NOT ALLOWED 


BYIE ±1 PRIMARY PROTOCOLS - X'Bl* 

SINGLE/MULTIPLE ELEMENT CHAINS ALLOWED IMMEDIATE REQST MODE 

DR/ER BOTH ALLOWED PLU TO END BRACKETS NO COMPRESSION 


BYTE 51 SECONDARY PROTOCOL - X'90’ 

SINGLE/MULTIPLE ELEMENT CHAINS ALLOWED IMMEDIATE REQST MODE 

ONLY ERs MAY BE REQUESTED SLU DOES NOT EB NO COMPRESSION 


SUES 6^71 COMMON PROTOCOLS - X '3080' 

NO FMHs BRACKETS ALLOWED HOST TO END BRACKET HDX/FF 

PLU/SLU BOTH USE EBCDIC PLU RESPONSIBLE FOR RECOVERY 

SLU 1ST SPEAKER SLU WINS CONTENTION 


BYTES 20 A 24i SCREEN/BUFFER SIZES 

(BYTES 20-23 USED BASED UPON BYTE 24 CONTENTS) 

BYTE 24: BASIC SIZE (LU TYPE 2 OR 3) 

X '■ 01 ’ : 12 ROWS X 40 COLS X'02’: 24 X 80 

X'7E’: SIZE IN BYTES 20-21 

X r -7F’ : SIZE IN BYTES 22-23 

BYTE 20 - # OF ROWS 

X'OC': 12 ROWS X '■ 18: 24 ROWS X '20 ? : 32 ROWS 

X'2B’: 43 ROWS 

BYTE 21 - # OF COLUMNS 

X'lC’: 28 COLUMNS X'32’: 50 COLUMNS 

BYTE 22 - # OF ALTERNATE ROWS 
VALUES ALLOWED SAME AS 20 

BYTE 23 - # OF ALTERNATE COLUMNS 

VALUES ALLOWED SAME AS BYTE 21 
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Unit 8: Review Quiz 

1. Which header format in the F'lU is determined based upon the 
PU type of a given device? 


2. How long is the TH header for a PU type 2 device? 



3. Which SNA layer generates the TH? 


4. Which host software component builds the TH? 




W ' / f 


5. Name the profiles used to describe SNA protocols for an SLU? 

ff t jp***' j# 


s/Y T* 


s 

6. Which table # in the host contains the profile numbers 
for Logical Units? *" 




7. Which SNA layer(s) functions are covered by: 

a) . an FM profile? 

b) . a TS profi1e? 

8. Having captured a bind imag^ being sent to a 3270 on a 
line monitor, which byte irj/the bind image would you look at 
to determine: 

a) Whether theN^ost cajT' ask for definite responses? Which 
bit in the by} 

b) Whether the/o270\Qan ask for definite and exception 
reponses?/which bit'C'sO? 


c) Whether the use of Bracket protocol is mandatory? 
WhLeh bit(s)? 
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UNIT a 


SNA LAYERS 


OBJECTIVES: 

AT THE CONCLUSION OF THIS UNIT, THE ATTENDEE SHOULD BE ABLE 

to: 

1. DESCRIBE THE FUNCTION OF MAJOR SNA LAYERS 

2. DESCRIBE THE RELATIONSHIP BETWEEN SNA LAYERS AND NAUs 

3. MAKE A HIGH LEVEL COMPARISON BETWEEN SNA AND OPEN 
SYSTEM INTERCONNECT (OSI) MODEL 
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<x u 


INTRODUCTION TO SNA LAYERS 


Storm in Utah, transmission no good 


D Make 

I 

D 

U S 

L 

0 

W 
T 

I 

V 

A 

T 

So U 
WILL IT 


sure to insert attribute characters 

But, what is the optimum route -from here to there 

D D CHI 
0 E A A T 
W V N N 
N I T D 
C L 

E E 

COMPUTE PAYROLL 

E THE STATION 


got data, but do U have CTS? 
FIT IN THE PRINTER BUFFER? 


! COMPUTE PAYROLL ! 


STN. ACTIVE? 


ATTRIBUTES 


PRNTR BUF SIZE? 


SLOW DOWN 


ROUTING INFO? 


STORM IN UTAH 


CTS? 



THE — LAYERS 

o FORMAL SPECIFICATION OF "SELECTED" FUNCTIONS IN A 
COMMUNICATIONS SYSTEM 

o SIMILAR FUNCTIONS GROUPED TOGETHER IN "LAYERS" 

o WHEN GROUPING FOR LAYERS, CONSIDER ONLY THE FUNCTIONAL 

SIMILARITIES AND NOT THE PRODUCTS THAT PERFORM THOSE FUNCTIONS 


o AN "ABSTRACT" VIEW OF AN ARCHITECTURE, LAYERS MAY NOT 
EQUATE WITH REAL PRODUCTS PRECISELY 

o ARCHITECTS MAY DISAGREE ABOUT THE PLACEMENT OF CERTAIN 
FUNCTIONS IN IN CERTAIN SNA LAYERS 
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Some selected -functions pe-formed in a communications network: 

1. Making sure that the next timing pulse is received before 
next data bit is presented on the line. 

2. Making sure that there are no logical errors in the contents 
of data (e.g. bad attribute or row, column address for 3270) 

3. Making sure that there are no 'transmission errors’ as data 
passes through each link. 

4. Figuring out optimum routing between points A and B, where 

A and B are separated by >1 link. 

5. Making sure that message is compatible with the end user 

medium, e.g. do not use attributes for a TWX device. 

6. Ensuring that message will not exceed the devic e buffer 
and thereby end up in the 'bit bucket’. 

7. If a message exceeds device buffer, break it up into smaller 
blocks. Before sending the next block make sure to wait for 
an acknowledgement from the device indicating that it 
has processed the previous message. 

8. Make sure that the message is not too long for a given link 

quality (too high an error probability), if too long divide 
it into blocks, receive 'no transmissions errors’ 

notification before sending the next block. 

9. Encrypt data for highly secure applications before sending 
it over the network. 


etc. 


EXERCISE! 

Assume that the functions identified above would not all be 
performed in a single software component. Since it is generally 
desirable to perform similar functions in the same program, 
divide the functions identified above into categories of related 
functions such that each category can be implemented in one 
program (or logic in hardware). 
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SNA LAYERS! INTRODUCTION 



END USERS: 
OPERATORS, 


HOST APPLICATIONS, TERMINAL 
MICROCODE IN A DEVICE 


NETWORK MANAGEMENT AND CONTROL, SESSION 
INITIATION/TERMINATION SUPPORT 






d-^-VXf 

/ DFC | 

*1 

TC 


yy 


l\ 



MAKE MESSGES COMPATIBLE WITH DEVICE 
MEDIUM OR APPLICATION NEEDS, MANAGING 
SCS AND OLDER FORMATTING CHARACTERS 

✓/ czr 

'MANAGING MSG FLOW IN A SESSION, 
CHAINING LONG MSGS INTO SMALLER ELEMENTS, 
ASSIGNING SEQ NUMBERS TO MSGS, LU-LU ACKS 

L-ti* t«lA 

CHECKING MSG SEO NUMBERS, 'PACING’, 
EXEPEDITE/NORMAL FLOWS, ENCRYPTION/DECRYPTION 


PC 

' \> ’*JL C<r>, 

DLC 


ROUTING, SEGMENTATION 


i —i 


v 


PHYSICAL 


LINK MGMT, EST/MAINT/RELSE LINKS, LINK LEVEL 
ERROR RECOVERY, SDLC IN SNA 


/t 





py-- /> 

ELECTRICAL INTERFACE WITH THE MODEM, 
RS232C, X. 21 ETC. .. - 
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Layers _in an SNA environment! 


1. Physical Control.! Data Terminal Equipment (DTE) to Data 

Communications Equipment (DCE) inter-face. SNA does not 
de-fine protocols -for this layer and accepts the already 
existing standards -for modems such as EIA RS232c. The new 
ANSI I standard x.21 is not yet very prevalent. 

2. Link Control. IDLC).! This layer provides protocols -for 

exchange o-f in-formation between two points o-f a 
transmission link. SNA defines Data Link Control (DLC) 
protocols only between end points of common carrier 
communications links or equivalents via the Synchronous 
Data Link Control (SDLC). Channel protocols, for example, 
for exchange of information between the host and the local 
NCP or other local devices are not defined by SNA and are 
implementation dependent. 

3. Path Control. i.PQLL This 1 ayer provides protocols for 

routing information through an SNA network. This layer 
keeps track of message paths between nodes, Transmission 
Groups (multiple links between two adjacent nodes for 
backup and throughput). It also provides segmenting (as 

against "chainining", see DFC) of messages to keep them 
compatible with the receiver buffer requirements and 
translates SNA network addresses to addresses that are 
recognized by remote devices. 

4. ICiiQsmi.ssi.gn Control. _(TC).! Provides protocols for 

checking sequence numbers (number generation is part of 
DFC), separating expedited flow from normal flow of data, 
"pacing" data transmissions so that the receiver is not 
flooded, and for encryption/decryption of data. 

5. Data Fl_gw Control. i.DFC).! Provides protocols to specify 

which of two end-users should transmit next, ability to 
divide long messages into a chain of smaller elements; 
assigns sequence numbers to messages for recovery 
purposes; prevents unsolicited messages in the middle of a 
transaction. Also provides protocols to verify that the 
message was processed correctly. 

6. Funct i_gn Management Data Ser.yi.ces i.FMDS)_! This layer 

provides a convenient means to perform any special 
processing unique for a given end user medium. While the 
architecture defines the location of this layer, the 
specific functions are implementation defined. Basic 
Mapping Support in CICS or Message Formatting Services in 
IMS are two examples of FMDS. 
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7. NAJJ Services Manager^. This layer provides -functions that 
are invoked primarily -for non-end user sessions. These 
sessions pertain to special -functions associated with an 
SNA de-fined control point called the Systems Services 
Control Point which by de-finition is in the host access 
method. This layer is primarily concerned with 
monitoring, control, and maintenance -functions -for the 
network resources. 

8- End User,!. End user -functions are not de-fined by the SNA. 

This layer includes application programs, terminal 
operators, and firmware in remote devices etc. 


Note!. The SNA architecture is still evolving. Related 
publications allude to certain functions which are not 
otherwise defined. Thus, it is to be expected that focus 
and emphasis of layer—functions will change as 

architecture matures. 
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SNA LAYERS DURING NORMAL FLOWS 


END 

USER 


FMDS 


DFC 


TC 


PC 


DLC 


PHYSICAL 


NOTES 

NOT ALL SNA LAYERS ARE ACTIVE 
NOR NEEDED FOR EVERY OPERATION 
IN THE NETWORK 

NAU_SVCS_MGR LAYER, FOR EXAMPLE, 
PLAYS NO ROLE DURING NORMAL DATA 
FLOWS AS SHOWN IN THE DIAGRAM 
HERE 

CONVERSELY, DURING THE SESSION 
ESTABLISHMENT/TERMINATION PHASE 
NAU_SVCS_MGR HAS A DIRECT INTER¬ 
FACE WITH PC LAYER AND OTHER 
LAYERS IN BETWEEN ARE ABSENT 
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SNA HEADERS AND LAYERS 


HEADER/DATA 

LAYER 

RESPONSIBLE 

HOST COMPONENT 
RESPONSIBLE 

• 

R U 

END-USER 

FMDS 

DFC 

TC 

CUSTOMER SOFTWARE 
TP MONITOR 

ACCESS METHOD 

* 

R H 

FMDS 

DFC 

TC i 

1 

l 

CUSTOMER SOFTWARE 
TP MONITOR 

ACCESS METHOD 

T H 

PC ! 

t 

1 

ACCESS METHOD 

NCP 

S D L C 

DLC ! 

NCP 


FMDS AND DFC PASS THEIR REQUIREMENTS TO TC, THE ACTUAL 
CONSTRUCTION OF RH IS DONE IN THE TC LAYER. 
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LAVERS, NAUs, AND PATH CONTROL NETWORK 


N 

A 

U 



NETWK.PC 


v 



"SNA IS A SET OF NAUs INTECONNECTED VIA A 
PATH CONTROL NETWORK" 
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HALF SESSIONS 


1 1 

1 1 

: end : 

END ! 

: USER i 

i i 

i i 

i i 

1 — -m — — * ...lu 

USER ! 

j 


i NAU.SVCS! 

I MANAGER i 

■ 




" 1 11 ' r ' . 

FMDS 

■ 

A 

t 

1 

1 

1 

1 

I 

FMDS 


DFC 

HALF 

SESSION 

1 

1 

1 

1 

1 

! DFC 


TC 

1 

1 

1 

1 

i 

V 

_ 1 

TC 


PC 


PC 


DLC 


DLC 


PHYSICAL 


PHYSICAL 


/ 


i NAU.SVCS! 
! MANAGER ! 
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APF'L 


F‘S 

(PRESENT) 


SC 

(SESSION) 


TC 

(TRANSPORT) 


NC 

(NETWORK) 


DLC 


PHYSICAL 


NOTE: 


OPEN 


END USER NEEDS, ULTIMATE SOURCE/DEST OF 
USER DATA, AND SESSION REQUESTS 


PRESENT INFO PRESERVING MEANING YET RESOLVE 
SYNTAX DIFFERENCES, OR MAKE DATA COMPATIBLE 
WITH APPL LAYER NEEDS 


ESTABLISH/TERM SESSIONS, MGMT OF FLOW CTL, 
DIALOGUE MGMT,QUARANTINE, EXP/NORM FLO 


OPTMUM NET SVC. AND QUALITY OF SVC CHOICE. 
SYMB TO NET ADDR TRANS, FLO CTL, END TO END 
ACKS, SEGMENTING/BLOCKING 

ROUTING/PATH, MASK DIFFERENCS IN TRANS AND 
NET TECHNOLOGIES, GEN NET ADDRESSES, DELIVER 
MSGS IN CORRECT SEQ, SEG/BLOCK 


LINK MGMT, EST/MAINT/RELSE LINKS, LINK LEVEL 
ERROR RECOVERY 


BIT TRANS BETWEEN LINK ENTITIES, SERIALI¬ 
ZATION, e.g. RS232C, X.21 


OSI IS THE NAME OF THE ARCHITECTURE 
BEING DEVELOPED INTERNATIONAL STANDARDS 
ORGANIZATION 


,SYSIEM_INTERCgNNECI„iOSIi_REFERENCE_MgpEL 
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SNA VS. OSI: PASS I 


SNA 


END 

USER 


FMDS: SPS 


DFC 


TC 


PC 


DLC 


PHYSICAL 


/ 


/ 


/ 


./ 



ISO 


APPL 


PS 


SESSION 


TRANS 


NETWK 


DLC 


PHYSICAL 


SPS * SESSION PRESENTATION SERVICES 
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SNA VS. OSI 


PASS II 


SNA ISO 


! END 

! USER 


i 

i 

i 

i 

APPL i 

1 

1 

1 

( 

1 

! NAU.SVC.MGR 

1 

1 

1 

1 

1 

1 

l 

i 

t 

1 

— pc * 

! FMDS 

I • 

i sns : sps ~ 

9 • 

1 • 



r o • 

i 

i 

i 

: DFC 

r. — ,r» ...ii _u_ .... .... _JL JJ - -» — — '■« L 

1 

i 

t 

i 

SESSION ! 

1 

I 

t 

1 

l 

. t 

. / 

/ ! 

1 

) 

! 

» 

i 

! TO 

... u. 1— 1 

1 

1 

TRANS ! 

1 

l 

i 

1 

1 

. / : 

/ ! 

1 1 

1 

1 

1 j 

t 

1 

1 

! PC 

1 1 

1 I 

NETWK ! 

1 1 

1 l 

1 

1 

I 

: DLC 

: PHYSICAL 

1 1 
1 1 

1 

1 

! ! 

S 

! DLC : 

1 

l 

! PHYSICAL ! 

1 

1 


SNS * SESSION NETWORK SERVICES 
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x.25: A DE FACTO INTERCONNECT PROTOCOL? 


SNA 


END 

USER 


FMDS 


DFC 


TC 


PC 


DLC 

’physical" 



—y< 


ISO 


APPL 


PS 


SESSION 


TRANS 


NETWK 


DLC 

’physical" 


’"tfe- 
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SNA LAYERS REVIEW QUIZ: 

For each of the functions described below. Identify the SNA layer In 
which It Is Implemented: 


a). Routing Information through the network. 


b) . Ensuring data Integrity across a transmission link._ 

c) . Monitoring the status of a network resource from the host access 

method. ___ , 

d) . Checking sequence numbers on messages received to ensure that none 

are lost. __ ’ 

e) . Generating sequence numbers on messages transmitted.__ 

f) . Ensuring that data Is not transmitted on the link unless the modem Is 

ready. _______ 

g) . A totally confused human being on how to use an allegedly "user 

friendly" device. _ 

h) . Inserting special control characters In a message depending upon 

whether It Is destined for a CRT or a printer. __ 





uil 



n n 

lAj 


i 

i 

I 

i 

] 

i 

i 

l 

i 

i 

i 

i 


i 
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UNIX 9 


SYSIEM GENERAIION CONSIDERATIONS FOR 
SNA IN AN NCP/VTAM ENVIRONMENT 


QiXICIIVESl 

AT THE CONCLUSION OF THIS UNIT, THE ATTENDEE SHOULD BE ABLE TO: 

1. DESCRIBE MAJOR SYSTEM GENERATION ACTIVITIES TO BE PERFORMED 
BY A CUSTOMER TO GENERATE AN SNA NETWORK 

2. IDENTIFY SELECTED VALUES CODED ON THE NCP SYSTEM GENERATION 
MACROS 

3. DESCRIBE THE ROLE OF MAJOR AND MINOR NODES IN VTAM 

4. DESCRIBE PROCEDURES FOR AUTOMATIC ACTIVATION OF NETWORK 
RESOURCES DURING SYSTEM 
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OVERVIEW OF SYSTEM GENERATION ACTIVITIES 

NCR DEFINITIONS: 

TABLES THAT CONTAIN PROFILES OF LINES, CLUSTER CONTROLLERS, 
CRTs, AND PRINTERS CONNECTED TO THE FEP 

VTAM DEFINITIONS: 

NETWORK PROFILES AS CODED FOR THE NCP ABOVE. VTAM NEEDS THIS 
INFORMATION BECAUSE IT IS THE SSCP AND HAS TO MANASE THE 
TOTAL NETWORK 

ADDITIONAL DESCRIPTIONS NEEDED BY VTAM INCLUDE HOST 
APPLICATIONS (HOST LUs), LOCALLY ATTACHED DEVICES, BIND 
IMAGE TABLE, LOGON TRANSLATION TABLES 


OPERATING SYSTEM DEFINITIONS 

OPERATING SYSTEM ALSO NEEDS TO KNOW THE FACT THAT VTAM WOULD 



VTAM 





ACF/NCP SYSGEN AND ACF/VTAM 


f PCCU SUBAREAM, 


! BUILD TYPBEIMICP, * < 

I I 

I I 


f NCP SYSGEN 


1 I 

1 1 

1 I 



0 

INFORMATION FOR 5 

ACF/NCP ONLY ! 

1 

1 

• • 

! INFORMATION FOR i 
! ACF/VTAM ONLY ! 

1 I 




v 


INFORMATION FOR BOTH 
ACF/NCP AND ACF/VTAM 
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NCR system generation and VTAMl 

As in all system generations (SYSGENs), NCP generation involves 
creation of various tables that describe each resource that the 
NCP would be communicating with. 

However, in-formation described in the tables is actually more 
than what the NCP needs to know. The tables also include 
in-formation that is needed by VTAM only. Any in-formation in the 
tables not applicable to NCP is ignored by it. 

Thus, the tables coded to create an NCP are coded once but 
-filed twice: 

Once as part o-f the NCP and this goes to the -front end. 

Second, as part o-f VTAM and this stays in the host. 

One o-f the easier ways to generate a malignant system is for a 
customer to file a different set of definitions for NCP than the 
one for VTAM. 
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SELECTED NCP SYSTEM GENERATION MACROS 



[Ti 

'Ufci 


1 

J 

I 

1 

I 

I 

I 

1 

I 

1 

I 

I 

I 

1 

I 
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NCP/VTAM MACROS 


PCCUi (Programmed Communications Control Unit). 

This macro is used to describe the NCP attributes to 
VTAM. PCCU macro contains in-formation such as: 


The subchannel number connecting this NCP to the VTAM host, 
the subarea number of the VTAM controlling this NCP. 

BUILD! 

BUILD macro describes features and capabilities of the 370X 
hardware and the NCP being generated. It provides 

information such as: 

Subarea number of the NCP, buffer size of the NCP 
buffers, highest subarea number assigned to any node in 
this SNA network, etc. 

HOSIl 

Host macro describes the characteristics of a host access 
method to the NCP. It contains information such as: 

Largest message size that this host access method 
can accept form the NCP, subarea number of this 
host access method, how many NCP buffers would be 
generally sufficient to receive messages from this 

access method. 

GROUP! 

GROUP macro describes a group of similar lines. Lines are 

considered alike if they all use the same link protocol and 

are all switched or all private. Common attributes of lines 
in the group need be coded only on the GROUP macro. 

LINE! 

LINE describes unique attributes of a line that are not 
defined on the GROUP definition. May contain values such 
as line speed, port address, etc. 


SERVICE: 

SERVICE macro specifies the order in which PUs (control 1ers) on 
the line are to be serviced. 


PU ICLUSIERi: 

PU (CLUSTER) macro describes the profile of a physical unit 
(cluster controller) on the LINE above. 


LU (TERMINAL^: 

LU (TERMINAL macro describes the profile a logical unit (device) 
on the PU above. 


GENEND! 

GENEND indicates the end of generation and provides some performar 
related option. 
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ILLUSTRATIVE SEQUENCE OF NCP/VTAM MACROS 


i 1 '/ 




Ml 


<y 


PCCU 

BUILD 

SYSCNTRL 

HOST 

CSB 

CSB 


DESCRIBE FEP TO VTAM 




-/M 


DESCRIBE NCP FEATURES 
OPTIONAL DYNAMIC FEATURES 
DESCRIBE A. M. TO NCP 
DESCRIBE SCANNER ON 370X 
IF ADDITIONAL SCANNER 


yte--* 




GRP1 

GROUP 

BEGIN DESCRIPTION SIMILAR LINES 

GRP1L1 

LINE 

UNIQUE FEATURES 

THIS LINE 


SERVICE 

ORDER IN WHICH : 

STNS SERVICED 

PU1 

PU 

DESCRIBE A PU 

ON THE LINE 

LU1 

LU 

LU PROFILE FOR 

ABOVE PU 

LU2 

LU 

• 

m 

IF MORE LUs, 

ONE / LU 

PU2 

PU 

• 

IF MULT. POINT 

LINE 


• 

LUs -for above PU 

• 

• 



GRP1L2 

LINE 

m 

• 

NEXT LINE IN GROUP, IF ANY 


GRP2 


GROUP 


START NEXT GROUP 'OF LINES 


LINE 


GENEND 
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/ Uc- 

***%. /t/c,./®* 

ILLUSTRATIVE OPERANDS FOR NCP/VTAM GENERATION: \ 


NCP1H1 


NCP1 


VTAM1 


GROUP1 


# 


LINE1 


PCCU 


BUILD 


CUADDR-01C , g3UBAREA=2, 
TYPGEN=NCP,SUBAREA=3, 


\ MAXSUBA=12, 


GROUP 




LINE 


HOST ^ Bfl f, E A-25iNIT S 2fiaMft-X?FRU^|7> 




LNCTL « SDLC, 
DIAL * YES/NO, 
TYPE = NCP, 


SERVICE ORDER = (-,-■) 


/OQft SO » 

•Jc-f* -4 s/ndf 


ADDRESS = 3705 port address, 

SPEED « 2400, LINE SPEED 

AUTO * YES, IF AUTO DIAL 

MAXPU = # OF PUs, 

TRANSFER = largest msg size. 


PUT 


ADDR ■ Hex Id o-f PU, 
BNNSUP = 3270, 
MAXDATA = bytes, 
MAXOUT = 7, 

PUTYPE * 


FOR 3270 PU_T1 
LRGST POSS MSG 
MAX SDLC FRAMES 
THIS PU TYP 1,2,OR 4 


VTAM ONLY VALUES: 


ISTATUS * ACTIVE, 


STRTUP STATUS OF PU 


LU1 LU L0CADDR=01,PACING=<2,2),... 

VTAM ONLY VALUES: 

DLOGMOD ■ BIND IMAGE NAME 

ISTATUS * ACTIVE, LU STRTUP STATUS 
LOGAPPL * CICS, AUTO LOGON TO CICS 
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DescrjLEtion of selected values from VTAM/NCP generation tabfesf 

PCCU Jablei 

CUADDR: Subchannel number of the subchannel connecting FEP to 

the host. 

SUBAREA: Subarea number o-f the VJAM connected to this NCP over 

the subchannel identified above. 

BUILD Jablei 

SUBAREA: Subarea assigned to the NCP being created. 

MAXSUBA: Highest subarea number that will ever be encountered by 

the NCP in this network. NCP uses this value to 
compute the SUBAREA/ELEMENT boundary in network addresses. 


HOSJ Jablei 

SUBAREA: Subarea number o-f the host access method that this NCP 

is connected with. 

GROUP Jablei 

LNCTL: Indicates the link protocol -for lines in this group, 

4540e lines must be in an SDLC group. 

DIAL: Indicates whether lines in this group are private ( = 

NO) or swithced < = YES). 

LINE Jablei 

ADDRESS: Port number assined to this line on the FEP. 

MAXPU: Approximate maximum number o-f controllers on this 

line. 

TRANSFER: Largest message (PIU, chain element, or segment) that 
will ever be received by the NCP -from any device on 
this line. 


PU Jablei 

name: Symbolic name ("PU1" in our example) assigned to this 

PU. 

ADDR: 1 byte hex ID o-f this controller, this ID goes in the 

address -field in the SDLC header. 


MAXDATA: Buffer size of this controller, any messages exceeding 

this number would be segmented by the NCP. This number 
should be 265 for 4540E 


PUTYPE: 


PU type of the controller being described, 2 for 4540E. 
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i status: 

LU lable: 
name: 

locaddr: 

pacing: 

DLOGIiODE: 

i status: 

logappl: 


Whether VTAM should automatically activate <=ACTIVE> 
this resource when it comes up. 


Symbolic name <"LU1" in our example) assigned to the LU 
being described. 

1 byte hex ID of this LU (CRT/Printer) within this 
controller. 

Pacing number -for this LU, a parasite, BIND value would 
override it. 

Name o-f the Bind image -for this LU in the Bind table. A 
value here alleviates the need for a Bind entry name in 
the Logon message. 

Whether VTAM should automatically activate (=ACTIVE) 
this resource when it comes up. 

Name of host application, e.g. CICS, with which VTAM 
would set up an LU-LU session for LU1 automatically 
when VTAM comes up. 
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ADDITIONAL. VTAM TABLES 


MAJOR/MINOR NODES: FIVE TYPES 


APPLICATIONS: 

NCPS: 

SNA LOCAL: 
NON-SNA LOCAL: 
SWITCHED PORTS 


EACH SUBSYSTEM (IMS, CICS, ..) A MINOR 
EACH PU AND LU ON THE NCP A MINOR 
EACH PU AND LU A MINOR 
EACH CONTROLLER AND DEVICE A MINOR 
ASSOCIATED PU AND LU ARE MINORS 



BIND IMAGE TABLES 

USS TABLES 

LOGON MESSAGES 
CUSTOMIZED ERROR MESSAGES 

START AND CONFIGURATION LISTS 
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example: applications major node 



VBUILD 

TYPE=APPL 

BEGIN 

APPL MAJOR 

CICS03 

APPL 

PRTCT“SECRET,.. 

1ST 

APPL MINOR 

IMSOl 

APPL 

PRTCT“SECURE... 

IMS 

IS 

NXT MINOR 




notes: 


1. MAJOR NODE CONTAINING CICS OR IMS MUST BE ACTIVATED 
BEFORE THE SUBSYSTEM CAN BE ACTIVATED UNDER VTAM 

2. TRANSACTIONS UNDER IMS OR CICS ARE UNKNOWN TO VTAM 


NAME CODED TO THE LEFT OF THE 'APPL’ KEYWORD 
BECOMES THE NAME OF THE MINOR NODE BY WHICH 
THE APPLICATION WILL BE KNOWN TO THE SYSTEM 



>.' \ 4 . 



4 / 
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START AND CONFIGURATION LISTS 


SIARI LIST: ATCSTRXX (XX=00-99) C " " “... 1 

“* ““ i’ 

1. CONTAINS STARTUP INITIALIZATION INFORMATION FOR VTAM 

SIZE OF VTAM BUFFERS, NUMBER OF BUFFERS 
SUBAREA NUMBER ASSIGNED TO VTAM 

HIGHEST SUBAREA NUMBER IN THIS SNA NETWORK f 

m 

m 

m 

m tyj, v 

OTHER INFORMATION 

2. THE ABOVE CAN BE PROVIDED ALTERNATIVELY ON VTAM START COMMAND 

£QNEI§yB£IIQN LIST! ATCCONXX <XX=00-99) ‘ 'V*' 

$ 

1. A MEANS TO CONTROL ACTIVATION OF NETWORK IN 

2. CONTAINS NAMES OF MAJOR NODES TO BE ACTIVATED 
WHEN VTAM COMES UP 



PARTS 

AUTOMATICALLY 
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i 

a 


1 

1 

1 

1 

] 

1 

1 

I 

I 

I 

I 

1 


1 


I 
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AN EXAMPLE OF VTAM STARTUP 


HOST 


• 

CHNL l 

FEP 

;— i _ 

—U-i 

1 1 

1 • 

NCP1 

! NETWORK 

.-2_ 


5_! i LOCAL ATTACHED 

i ! RJE 3790 COMPLEX 

CICS 

TSO 

IMS 


VTAM NODES OF INTEREST 


MAJOR 


ASSOCIATED MINORS 


JOBX 


CICS, TSO 


JOBY 


IMS 


L0C3790 


RJE COMPLEX, 1 PU AND 3 LUs (ASSUME 3 
COMPONENTS) 


NCP1 


LINKS, PUs, AND LUs 
(SPECIFIC NUMBERS 



CONNECTED TO THE NCP 
NOT IMPORTANT FOR 


THIS 
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WHAT HAPPENS DURING VTAM STARTUP 



START VTAMNET,,,(LIST=01) 

3 



NOTE: FOR DOS/VS, ATCSTRXX AND ATCCONXX ARE APPENDED TO B, 

GIVING B.ATCSTRXX AND B.ATTCONXX. 
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What.Happens Puring_ACF/VTAM_Startup: 

Diagram on the opposite page shows some o-f the major activities 

that take place when the system operator starts ACF/VTAM. 

1. Operator enters the START command indentitying NETATT as the 
procedure that contains the JCL. Also note the option 
LIST=01. This identifies which start list to use. More of 
this in a moment. 

2. The operating system receives the START command loads the 
appropriate ACF/VTAM modules from the disk to the main 
storage. 

3. As ACF/VTAM initialization routine gets control, it looks at 
the set of options specified by the operator, LIST=01 in 
this case. 


Or in other words, we want to bring up ACF/VTAM in this case 
using the start list ATCSTR01. 

4. ACF/VTAM loads ATCSTR01 list into main storage and discovers 
that network configuration to be brought up in C0NFIG=02 or 
ATCCN02. 

5. VTAM reads configuration list, ATCC0N02, into main storage. 
In this case we have two major nodes in the configuration 
JOBX and L0C3790. 

6. ACF/VTAM reads JOBX major node statements and builds RDT 
entries for JOBX. 

7. ACF/VTAM reads L0C3790 major node statements and builds RDT 
entries for L0C3790. 

The following page shows the ACF/VTAM view of the network at this 

point. 
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ACF/VTAM’S VIEW OF THE NETWORK USING LIST=01 


0 


APPLS 



V 

T 

A 

M 


JOBX 


CICS 

TSO 


LOCAL 3709 

PU1 

LU1 

LU2 

LU3 
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Figure here shows ACF/VTAM's view of system at this time. 


RDTs at this time should contain: 

JOBX 

CICS 

TSO 

LOCAL 3790 
PU1 
LU1 
LU2 
LU3 

This does not, however, mean that these F'Us and LUs are activ 
<i.e., they have SSCP-PU and SSCP—LU sessions). That woul 
depend upon their ISTATUS specification in the PU and LU macros. 
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MODIFYING THE NETWORK 




VARY NET^D=NCP1 





j£~- 







ACF/VTAM 




NCP 

LOAD LIBRARY 



4(OPTIONAL) 


i ’ 


€>* 


SYSl.VATMLST 


NCP GEN 
STATEMENTS 


,X \ r r~ X 

/M 
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Modi f yi ng ..Network _Conf i quration: 

Once the network has been brought up using the start list, 
modifications can be made to the network using the ACF/VTAM 
operator command VARY. 

For example, in the first example in this module (with LIST=01) 
we did not bring up NCP or any of the associated network. 


Say, at this point we now want to activate the NCP and rest of 
the network. To be able to do that we have to know the name of 
the NCP major node - which in this case is NCP1. The command in 
this case is: 


VARY 

NET, ACT, ID=NCP1 

vary: 

command code 

net: 

Identifies this command 

act: 

For "activate" 

ID: 

The resource ID, NCP1. 


for VTAM 


VTAM 




Unit: Review Qui 


Z 


1. A VTAM user with a large network is unhappy because: 

a). It takes a very long time to bring up the network since 
operator has to activate all controllers and devices one at 
a time <100 devices). Operator errors make an already bad 
problem worse. 

Can anything be done to help the customer? 


b). Terminal operators in the field (end users) make too many 
mistakes in entering required logon messages in the right 
format. It causes loss of productive time, bad public 
relations, and unnecessary calls to AT&T for trouble shooting 
when it was really an operator error. 

Can anything be done to help the customer? 


2. On a new customer site, a 3270 clusters work fine except for 

one application where the operator is required to enter full 
screen messages. Any time such a message is entered, the NCR 
rejects it with an exception response. Line monitor shows 
that NCP^ent an SNA sense code of x'8010' <"PIU too long") 

to the^ 4MI. You have checked that the segmentation is 
being performed properly by the 4aB9T. 

3270 

A customer error was the cause of the problem. Can you 
identify the customer error? 

3Z7Q ' 

3. Customer is unable to activate one of the WKMZt controllers 
on a line (other^^lB^ control 1 ers work fine on the same 
line). Host sends the ACTPU command to the controller 
(activation command can be seen on the system log) but no 
response is returned by the controller. At the same time, 
the line monitoring equipment shows no ACTPU commands coming 
down the line for the controller in question. 

A customer error was causing the problem. Can you identify 
the error? 




UNIX 10 

ACF/TCAM OVERVIEW 


QBJECIIVESl 

TO IDENTIFY VARIOUS SOFTWARE COMPONENTS 
OF ACF/TCAM 

TO DESCRIBE THE FUNCTION OF MESSAGE CONTROL 
PROGRAM (MCP) AND MESSAGE HANDLERS (MHs) 

TO DESCRIBE VARIOUS NAUs IN A TCAM ENVIRONMENT 

TO DESCRIBE VARIOUS DEFINITIONS NEEDED TO 
SUPPORT A GIVEN NETWORK IN A TCAM ENVIRONMENT 
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HIGHLIGHTS OF ACF/TCAM 


o NETWORK CONFIGURATION TRANSPARENCY 

- APPLICATIONS DEAL WITH SEQUENTIAL 
AND NOT WITH NETWORK DEVICES 

o RELATIVELY GREATER DEVICE INDEPENDENCE 

- POSSIBLE TO DO CERTAIN AMOUNT OF EDITING 
WITHIN TCAM, INSERT/STRIP CONTROL CHARACTERS 

o SUPPORTS VARIETY OF OLD AND NEW PROTOCOLS 

- ALSO WORKS WITH BOTH NCP AND EP 

o AS A QUEUED ACCESS METHOD, ALLOWS: 

- ASYNCHRONOUS INPUT/PROCESSING/OUTPUT 

- WARM RESTART AFTER SYSTEM FAILURE 

- BATCH TESTING OF APPLICATIONS 

o HAS BUILT IN MESSAGE SWITCHING CAPABILITY 

o VERY COMPLEX, HIGH DISK QUEUING OVERHEAD 

o WITH THE NEW SUBSYSTEM INTERFACE, IT CAN 
EMULATE ACF/VTAM 
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ACF/TCAM TERMINAL SUPPORT 


o WITH EMULATION PROGRAM 

SS 

BSC 


o WITH NETWORK CONTROL PROGRAM 

SS 

BSC 

SNA 


o LOCAL ATTACHMENT 
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ACF/TCAM SOFTWARE COMPONENTS 


OS VS 


INITIATOR 


MCP 

- SSCP 

- ACTIVATE/DEACTIVATE 

- MHs 

- SERVICE FACILITIES 

- SNA HOST LUs 


ACF/TCAM APPLICATIONS TSO 




! 

I 

• 

a 

a 

i 
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ACF/TCAM MESSAGE HANDLERS 


MESSAGE 

CONTROL 

PROGRAM 


MESSAGE 

PROCESSING 

PROGRAM 



DMH 


AMH 

IN 


IN 

COMING 


COMING 

GROUP 


r — 


GROUP 



C 0 



OUT 




OUT 

GOING 


E 


GOING 

GROUP 


U 


GROUP 


m 



S! 
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ACF/TCAM_QyEUES 

o WHY QUEUE: 

UNPREDICTABLE ARRIVALS 
TEMPORARY CONGESTIONS 

o CRITERION FOR COMMON ELEMENTS ON A QUEUE: 

Q BY DESTINATION 

o QUEUING OPTIONS: 

MAIN STORAGE QUEUE 

DISK QUEUE 

NON-REUSABLE 

REUSABLE 

MAIN STORAGE WITH DISK BACKUP 
NON-REUSABLE AND USABLE 
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ACF/TCAM 


SSCP 


mm 


Q 


Ml 



U 


eth 

WH 


E 

U 


mf. 


E 



TRADITIONAL (DCB) INTERFACE 
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UKICAI WITS ffl (Q/m _ H 

ACF/TCAM 

SSCP 


i 

SUBSYSTEM CACB) INTERFACE (Y2R2) 


c 

a/p 

I 

a/p 

c 

a/p 

s 

a/p 

[qj) 




DEFINING A MESSAGE CONTROL PROGRAM 


o ACF/TCAM PROVIDED MACROS 

o OPTIONAL CUSTOMIZATION WITH ASSEMBLER CODE 

o MACROS GENERATE CONTROL PROGRAMMING AND TABLES 
o ASSEMBLED AND LINK EDITED AS AUTHORIZED PROGRAM 
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hcp 



TCAM: MEP AND OTHER PROGRAMS 


TCAM-12 







TCAM-13 








DCB 

DSORG—.... 

DCB 

DSORG=TX,.... 

DCB 

DSORG-TR,... 

PCB 

TTABLE 

OPTION 

• 

• 

• 

• 

■ 

t 

*. 

1 

1 

1 

n 

X 

£ 

• 

■ 

• 

GROUP 

MH=_ 

TERMINAL 

TERM=LINE, . . . 

1 

1 

1 

TERM*327C,GROUP* 

1 

1 

1 

1 

TERM=327R,GROUP* 

l 

1 

1 

1 

TERM-327C,_ 

1 

V 

• 

• 

TERM*327R, .... 

m 

m 

GROUP 

MH*. 

TERMINAL 

1 

TERM-LINE,... 

1 

1 

1 

1 

TERM*PUNT,... 

1 

V 

• 

■ 

TERM*LUNT,... 

■ 

■ 

TPROCESS 

■ 

• 


• 

• 

INVLIST 



ONE/FILE 
ONE/LINE VIA EP 
ONE/3705<NCP) 

ONE/APPLICATION 

BEGIN NETWORK DEFINITIONS 

OPTIONAL CTRL, EDIT INFO 

NON-SNA LINES VIA NCP 
NON-SNA LINE, ONE/LINE 
3270 BSC CLUSTER 
3270 DEVICE 
CONTINUE 

EP DEFINITIONS.. . 

START SNA DEFINITIONS 
SNA LINE 

ONE/PU ON THIS LINE 
ONE/LU ON THIS PU 

ONE/APPL MSG Q 

POLLING LISTS (EP) 
SWITCHED LISTS 


ICAM_MCPi_RESOLJRCE_DEFINIIigN_IABL.ES 
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o ALL DEFINITIONS AS IN SAME DOMAIN RESOURCES 
ARE IN THE MCP 

o TO INDICATE THAT THIS IS AN MSNF ENVIRONMENT 
MUST CODE FEATURE * NETWORK ON THE INTRO 
MACRO IN THE MCP 

o CROSS DOMAIN RESOURCES MANAGER AND CROSS DOMAIN 
RESOURCES ARE DEFINED IN THE TERMINAL TABLE IN 
A MANNER SIMILAR TO THE SAME DOMAIN RESOURCES. 

o CROSS DOMAIN DEFINITIONS MUST BE CODED AFTER 

ALL SAME-DOMAIN DEFINTIONS IN THE TERMINAL TABLE. 

o TCAM MAINTAINS A CROSS DOMAIN RESOURCE VECTOR 

TABLE (CDRVT) FOR CROSS DOMAIN RESOURCES. CDRVT 
OPERAND ON THE INTRO MACRO SPECIFIE THE NUMBER 
OF CROSS DOMAIN RESOURCES TO BE SUPPORTED. 

o FOR DESCRIBING NETWORK ROUTES TCAM DOES NOT HAVE 

A PATH MACRO. THE MACRO USED IN THIS CASE IS 
CALLED IEDRTDEF. 

(NOTE: TCAM DOCUMENTATION REFERS TO SECONDARY LOGICAL UNITS 
AS OUTBOARD LOGICAL UNITS (OBUs)) 


MSNF CONSIDERATIONS FOR TCAM: INRODUCTION 
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NOTES: 


INTRO 


......FEATURE-NETWORK f , 

• m m m n CDRVT—H * ... m 

• 

• 

• 

• 

SAME 




D 0 M A I 

N 



D E F I N 

• 

• 

T 

T I O N S 


• 

• 

TERMINAL 


TERM=LINE,... 

LINK TO ADJ NCP 

TERMINAL 


TERM=ANCP,... 

ADJACENT NCP 

TERMINAL 


TERM=CDRM,... 

CROSS DOMAIN CDRM 

GROUP 



DUMMY GROUP 

TERMINAL 


TERM-LINK,... 

ONLY IF THIS TCAM.. 

TERMINAL 


TERM=PUNT. 

..IS BACKUP HOST 

TERMINAL 


TERM=LUNT._ 

CROSS DOMAIN LU 

IETRTDEF 


m m m m 

CROSS DOMAIN ROUTE 


1. DUMMY GROUP MACRO HAS NO EFFECT ON CD LINKS AND 
PUs. CD LU-LU FLOWS ARE AFFECTED. 

2. ALL RESOURCES BELONGING TO THE SAME CROSS DOMAIN 
MUST FOLLOW BELOW THE TERM=CDRM MACRO FOR THAT 
DOMAIN. 

3. IF BOTH THE PARTICIPATING DOMAINS ARE RUNNING 
ACF/TCAM, IT IS POSSIBLE TO HAVE PSEUDO CROSS¬ 
DOMAIN SESSIONS FOR SNA DEVICES ALSO. 


TCAM CROSS DOMAIN DEFINITIONS: OVERVIEW 
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dULIIELi SYSTEMS NETWORKING FACILITY 
( M S N F ) 


QlJEQIiyis 


TO DESCRIBE THE FOLLOWING DEFINITIONS NEEDED IN AN 
MSNF ENVIRONMENT: 


1. CROSS DOMAIN RESOURCE MANAGER MAJOR NODE 

2. CROSS DOMAIN RESOURCES MAJOR NODE 

3. PATH TABLES 
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MULTIPLE SYSTEMS NETWORKING FACILTV (MSNF): DEFINITION 


• • • m 

! HOST!.! 'TERMINAL. ! HOST 2 ! 



: H0ST3 
! AF’F'L 


AN ABILITY TO ACCESS ANY APPLICATION IN ANY HOST FROM ANY 
TERMINAL.AND VICE VERSA USING A COMMON NETWORK 


MSNF“2 








SNA MyItiglj? Systems Networking Facy (MSNF ) i 


MSNF protocols 
network. These 
systems, access 
so long as each 


let you connect multiple hosts on a common 
hosts do not have to have the same operating 
methods or control programs (CICS, IMS etc.) 
location can support MSNF protocols. 


Some of the major resons for MSNF are: 


- Resources sharing extended over multiple systems. 

- Greater flexibility and possible reductions in 
network cost. 

- Increased availability and reliability. 


MSNF 




msnf: 


KEY TERMS AND CONCEPTS 

SSCP/DOMAIN/OWNERSHIP 

SUBAREA/ROUTINO 

SSCP/CDRM/NON—OWNED RESOURCES 


ft 
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hISNF: Key t^rms and Concepts 

SSCP/Domain/Ownershi # B£ One? of the -first questions to be 
resolved in a multiple host environment is deciding which 
host is responsible for which part of the network- For 
this purpose each resource in the network will be”owned” 
by an SSCP who will be responsible for its management. 
All resources (lines, PUs, LUs, remote NCF's) owned by the 
same SSCP constitute the "domain” of that SSCP. 

§ybarea/Rgutingi To determine routing paths through the 

network each SSCP and NCF' is assigned a unique number 
called its "subarea" number. Network paths between two end 
points are then specified via the subarea numbers of the 
i nterveni nq NCF's/SSCPs. 


S?Q[:!/GQ!5dL.N2QzQwned Resources: What about resources that 

are not. owned by a given SSCP? 

First of all, to distinguish them from the owned (i.e. same- 
domain) resources they are called cross-domain resources^ 

To manage communications with cross-domain resources each 
SSCP has a special component called the Cross Domain 
Resource Manager 1CDRM) ._ 
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MSI JF: ASS IGNING OWNERSHIP 

SYS - A 
SSCP - A ! 

I 

CDRM - A ! 

I 

I 

SA = 2 ! 


I 


: NCP-A ! 
: SA = 4 i' 


pc- 

£ys - B 
SSCP - B 
CDRM - B 
SA = 10 


NCP-B ! 
SA = 8 ! 


! NCP-C ! 
: SA = 6 ! 


OWNER •’ S RESPONSIBILTY? 

CRITERIA FOR ASSIGNING OWNERSHIP? 

IDENTIFYING OWNED AND CROSS-DOMAIN RESOURCES? 
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I 

I 

I 

I 

I 

I 

i 

I 

I 

I 

I 

I 

I 

I 

I 

I 

I 

K 

I 


M B N F: A s s i g n i n q O w n e r s h i p 

J .0 91.1 9 9 t i g n £ o r o w n e r : 

a) All logon requests tor resources in this domain will be 
processed by this SSCP. Once the session initiation is 
completed, ownership plays no role. 

h> Owning SSCF* must have the appropriate Logon Mode Table, 

Bind images and LJSS Tables needed to process logons tor all 
its resources. 


How to assign ownershijo^ 

a) G 9 9. 0 . C§_ 12 b. 1 g. a 1 ELQ'iiOQit'jil Generally, a minor and 
irrelevant issue in assigning ownership. 

b) Add! i9 a t 1 o n Considerations:. It a terminal is going to 

be dedicated mostly to one application, its ownership 
should be assigned to the host containing that 

appl i. cat i on . 

c ) Qporat ional Consider at ians£. Which location is going 

to be responsible tor tracking trouble reports, 
requesting maintenance, doing tollow-ups, and controlling 
this part ot the network. 

d) 6y.t.t)9.Ci.?. a £i20 £.9D5i£!^!C a ti9D^l Not a very common 

consideration but tor sensitive systems, authorization 
and logon processing could conceivably be assigned to a 
specitic SSCP. 

Each SSCP contains two tables 
with descriptions ot all the resources. One ot the 
tables contains descriptions ot all the owned resources 
and the other one that at all the cross-domain 
resources. The latter is known as the Cross Domain 
R e s o u r c e Tab _1 e._ 
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liSNF: 


CROSS DOMAIN FLOW 


SYS - A 

TSQ 7 IMS' 

SSCP - A 
CDRM - A 
SA = 2 


OWNED 


pc^ 

SYS - C 

'cics 7 jes" 

SSCP - B 
CDRM - B 
SA = 4 



n 


LOGON TO CICS OWNED BY SYSTEM 


CROSS-DOMAIN 


B 


OWNED 


CROSS-DOMAIN 


TSO 

: C/Ci’ 

exes. 

• r$>c> 


! JT/rS 

JES. 

! X>V_5 

u^A 


luB 

! Z-6/^ 

<? 


(jTcTod) (sVSA) 

r~ 






I 

I 

1 

I 

T 

i 

J 

I 

I 

1 

I 

1 

I 

1 


cpRM, r 

JUL _ 

(c&GrO'S 7*o ^ys<z. 
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Cross-Domain Data Figw 


1. NCR, SA=3, receives the logon request -for CICS from LU1 
and -forwards it to the host owning LU1, SYS-A. 

2. SSCRA in SYS-A determines that CICS is not a local 
resource and forwards the logon request to its cross-domain 
manager 5 CDRMA. 

3. CDRMA goes through the cross-domain resources 
definitions and determines that CICS is a CD resource. 

4. CDRMA sends the SNA command CDCINIT to CDRMC along with 
E< IND image name. 

5. CDRMC verifies that LU1 is defined as a CD resource to 
System C and that CICS is running and accepting logons. 

6. When both CDRMs are satisfied of the legitimacy of the? 
request, CICS logon exist is driven. If CICS accepts 
the logon, it causes the BIND command to flow to LU1. 

7. If Lu.l accepts the BIND, the cross-domain session is 
in place. 

8. All communications from now on involve only LU1, NCR 
(SAS), NCR (SA10), and System C. The cross-domain may 
continue even if System A goes down. System A is not. 
needed for session termination either. 
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NETWORK TO BE USED AS AN EXAMPLE FOR MSNF 
DEFINITIONS 


fyf 

pC 

AA 

SYS-A 

SYS-B 

SYS-C 

SSCF'A 

SSCPB 

SSCF'C 

CDRMA 

CDRMB 

CDRMC 

SA=2 

SA=4 

SA=6 

IMS 

TSO 

CICS 


NCPA 

SA=3 


NCF'B 

SA=5 


NCPC 

SA=7 


LIJA 


LUB 


LUC 


utks>'-iyp£ 



M Itk 

w $4 


/ 



EUmEV, 


f 


y 

4» 



’* 4 ■ 

: W 

* I 


I 


I /l 

■ i, -.y ■ ^ 

■%0P . A 

# 
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I 

I 

I 

I 

r 

i 

i 

i 

i 

i 

i 

i 

i 

f 

i 

i 

i 

i 

i 


additional definitions needed for msnf 


1. NAMES OF ALL CROSS-DOMAIN RESOURCE MANAGERS - 



NAMES OF ALL CROSS-DOMAIN RESOURCES - 
CROSS-DOMAIN RESOURCES MAJOR NODE 

DESCRIPTIONS OF CROSS-DOMAIN ROUTES- 
PATH TABLES. 




Tknr 





£*J, 



r t c s 

- 


tA Cm. 

C. 

C <&/^f*f 
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CDRM MAJOR NODE 


(NAME) 

(NAME) 


VBUILD TYPE=CDRM 

CDRM SUBAREA=N 

ELEMENT=I 

ISTATLJS=ACTIVE/INACTIVE 



MSNF-12 




CDRM Major Node 


VByiLDi 

name: 

TYPE*CDRM: 

CDRMj 

name: 

SUBAREA* 

ELEMENT* 

ISTATUS* 


Begins a major mode 

Optional, it defined must be unique, leave 
b 1 an k 

Identifies it as a CDRM node 

Defines a CDRM, need one per CDRM 

Required, identifies the CD resource 

Subarea number of the host SSCP of which 
this CDRM is a part. 

Must be 1 for ACF/VTAM or 0 for ACF/TCAM 

Specifies initial status of this manager as 
active or inactive. 
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CDRSC 


CROSS DOMAIN RESOURCES MAJOR NODE 


(NAME) 

(NAME) 


VBUILD TYF'E-CDRSC 

CDRSC CDRM=CDRM NAME 

ISTATUS=ACTI VE/ INACTIVE 
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Cross Domain Resources Major Node 
VBUILD: 

name: Not needed, do not code, if coded must be 

unique. 

TYPE=CDRSC: Identifies the beqining of the cross-domain 
resources major node. 

CDRSC: Defines a £rQ5£™domain C®S9yCE®i. QEEd one p_er 

CD resource^ 

narne^ Regui^red^ must be the network name of the LU 

CDRM:_ Name of the QDRM i_n the host that owns th i_s 

cross-domain resource. 


ISTATUS 


Initial status ACTIVE/INACTIVE. 
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PATH TABLES: DEFINING ROUTING INFORMATION 
(PRE-REL. 3) 

o CODED IN EACH VTAM AND EACH NCR 
o TABLES DIFFERENT IN EACH NODE 

o FOR EACH DESTINATION, PATH TABLES IDENTIFY THE NEXT NODE 
IN THE PATH 

o MULTIPLE TABLES MAY BE NEEDED TO COVER ALL DESTINATIONS 


TWO DEFINITIONS: 

ADJACENT NODE: A NODE NO MORE THAN ONE LINK AWAY 


DFRT T WAT T QM h!QnP; 


ANY 


Kinne- i.iLjTr'Lj 

• *■ *• i • <& w« i 


t r* Kirv-r /\ k j 
jl w* imu i nr-i 


An *r a r\r-v i-p 

nuu r-iL^c.iM I 


ADJSUB=n, DESTSUB= (>:, y, . . . ) 


PATH01 


PATH 



Path Jables:. as mentioned earlier. Path Tables are used to 
describe the route -for PIUs between two end points. 

Path Tables are defined separately in ACF/VTAM and ACF/NCP 
using the? PATH macro. Though the contents of entries differ 
on the PATH macro between VTAM and NCP the format of the 
macro used is exactly the same as follows: 

PATH: Name of the macro to describe a path. 

PATH01: System designer provided name for this path. 

Eight (8) character name using standard System 
370 assembler conventions. Name must be coded 
on the PATH macro. 

ADJSUB and DESTSUB: In the node in which this statement 

is coded, deliver all messages for destinations, DESTSUB, 

with subareas (x,v,-) to the subarea "n", ADJSUB, as the 

next node in this path. 

Or in other words, deliver all PIUs for destination subareas 
<x,y,—-> to subarea ■’n " . Subarea ? n ' , in turn, through 
its own PATH statements would determine where to put the F'lU 
nex t. 

In the example shown, all PIUs destined for subareas 2, 4, 

and 8 will be delivered by this node to an adjacent node 
with subarea number 18. Subarea 18 node will know what to 
do with this PIIJ next. 

It might, be worthwhile to recollect that destination subarea 
of a PIU is specified in the TH as part of destination 
network address. 
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PATH DEFINITION 


EXAMPLE (PRE-REL. 3) 


SYS-A SYS-B 



ADJSUB=4. 
DESTSUB=(5,2) 


ADJSUB=5„ 

DESTSUB=2 



ADJSUB=4, 
DESTSUB=(1, 
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Path Definition Example: 

Shown in this diagram are examples o-f PATH statements. Before 
looking at specific examples, here are additional consi der at i ons 
to be aware o-f in designing PATH STATEMENTS: 

1. Each destination subarea must be covered in some PATH 
statement. 

2. Path statements must use the most direct (shortest) path. 

3. Adjacent subareas must not be coded as destinations. (Every 
one knows who their adjacents are) 

Path statement -for system A: 

PCI PATH ADJSUB=4,DESTSUB=<5,2) 

means that this host should deliver all messages -for 
subarea 5 or subarea 2 to subarea 4 and subarea 4 would 
know what to do with it. 

Other statements can be interpreted in a similar manner. 
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UNIT 11 


ACCESS METHODS REVIE W. NTO. AND NETWORK.MANAGEMENT 


QIJiQIIVESi 

TO COMPARE AND CONTRAST VARIOUS ACCESS METHODS 
DISCUSSED IN THIS COURSE 

TO DESCRIBE NON-SNA DEVICE SUPPORT THROUGH THE 
USE OF NETWORK TERMINAL OPTION (NTO) 

TO PROVIDE OVERVIEW OF COMMUNICATION NETWORK 
MANAGEMENT (CNM) PRODUCTS: 

- NETWORK COMMUNICATIONS CONTROL FACILITY 

(NCCF) 

- NTEWORK PROBLEM DETERMINATION APPLICATION 

(NPDA) 


10.1 







1. EXTRA COST SOFTWARE-PACKAGE TO EXTEND NCP 
CAPABILITIES TO SUPPORT CERTAIN NON-SNA DEVICES, 

2. runs with NCP in LOCAL 3705. 

3. MAKES THE FOLLOWING DEVICES LOOK LIKE SNA DEVICES TO 
HOST: 

IBM 2740/2741 
IBM 3780 

IBM 1750 and 3750 (PBXs) 

TVIX 33/35 

4. NO AUTO CALL OPERATIONS. 

5. DEVICES SUPPORTED THROUGH NTO ARE ALSO CALLED NTO 
DEVICES. 

6. NTO MAKES THESE DEVICES LOOK LIKE A PU.T1. LU SESSION 
TYPE 1 SUCH AS IBM 3767. 


NETWORK TERMINAL OPTION (NTO): INTRODUCTION 


10.2 




1. NTO DEIVCE SENDS NATIVE MODE (BSC/SS) DATA TO NCP. 


2. NCP CONVERTS IT TO A FID 0 FORMAT AND SENDS IT TO NTO. 

3. NTO CONVERTS FID 0 FORMAT DATA TO FID 1 FORMAT. 

k, NCP SENDS FID 1 DATA TO THE HOST. 

(HOST TO NETWORK: HOST SENDS FID 1 DATA, NTO 
CONVERTS IT TO FID 0, NCP CONVERTS FID 0 TO NATIVE 
MODE). 

NOTES : ' I) NTO APPEARS AS AN SSCP WITH ITS OWN 
NETWORK ADDRESS, 

II) USS TABLES MUST BE DEFINED TO REMOVE 
, CONTROL CHARACTERS SUCH AS TABS, 

BACKSPACE, ETC. 


NTO: OVERVIEW OF OPERATION 
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1. Extra cost software packages for use in SNA environment 

2. Each runs as an application in the host computer 

) 

5, NPDA CAN NOT BE USED WITHOUT NCCF 



NCCF/NPDA:. INTRODUC TION 


10.4 



COMMUNICATION NETWORK MANAGEMENT (CNN) 


1. CNM - A TERM OFTEN USED TO REFER TO NCCF/NPDA AS A GROUP 

2. A GENERIC TERM, NOT A PRODUCT 

3. IBM USES THE TERM TO REFER TO A "SYSTEMATIC METHODOLOGY To 

Operate And Manage A Complex Network" 

A. Presently, one way to implement CNM capabilities is by 
using NCCF/NPDA 

3. Tied into IBM products such as their "SMART" modems and 
cluster controllers 

6. Practically, mandatory in an MSNF or otherwise complex 
network 


NCCF/NPDA: WH ER E THEY FIT IN SNA 


10.5 



1960s 


Ut*. 


Simple systems, no network management tools in BTAM, 

COMPLETELY USER RESPONSIBILITY 


l&SLl 7Q? 



CICS AND OTHER MONITORS WITH MASTER TERMINAL 
CAPABILITY, LIMITED TO NETWORK OWNED BY THE MONITOR 


2. TCA1 TAKES NETWORK MANAGEMENT OUT OF APPLICATIONS, 
WITH TCS EXTENDED CONTROL OVER MULTIPLE HOSTS, EACH 
HOST MUST HAVE TCS, 




VTAM HAS NETWORK CONTROL AS AN INTERGRAL PART OF SSCP, 1977 
TCAM ALSO GAINS SSCP CAPABILITY 


1976 


NOSP, FIRST PACKAGE FOR NETWORK MANAGEMENT OUTSIDE ACCESS 

method (VTAM ONLY) 


1978 


l 

fin 

i 

I 

I 

I 

1 

1 


NCCF, enriched NOSP, for both TCAM and VTAM, NPDA replaces 
FERS (CICS) and DEMF (CICS and IMS) as one integrated 
package 


IB M CNM : HISTORIC EVOLUTION 



1. 


Network master-terminal functions 




2. IBM PROVIDED commands/user enhancement 

3. Interrogate/change status of network resources 

4. Submit cross domain commands to NCCFs in other domains 

NPDA 

1. Runs under control of NCCF 

2. Collects network error statistics on a Data Base 

3. Identifies network errors. Suggests corrective actions 

4. Displays errqr/diagnostic information. 

5. An operator can invoke NPDA functions from an NCCF 

TERMINAL 


NCCF /NPDA; WHAT TH EY DQ (OVERVIEW) 


10.7 




HOST - 1 HOST - 2 



Only way to manage on interrogate cross domain 

RESOURCES IS THROUGH NCCF 


MSNF AND NCCFi CROSS DOMAIN COMMANDS 





NCCF/NPDA; OPER ATI ONAL OVERVia 




ACF/VTAM OR ACF/TCAM 


NCCF 

VSAM 

FILE 


VSAM * VIRTUAL STORAGE 
ACCESS METHOD 


IBM MICRO BASED MODEM 



IBM MICRO BASED MODEM 


NPDA: ERROR STATISTICS 
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37 OX 

Channel adapter errors 
Scanner errors 

Instruction exception (program checks) 

Miscellaneous interrupts 

(need 370X REFS for interpretation) 

LINK- LE V EL 

Modem interface (e.g. DSR check, DSR not up within 3 SECS 
of DTR) 

Hit count 

Link quality (phase Jitter etc.) 

Number of times carrier cost 

PE VJX£.(Py.)-L E V£L 

9 

Depends upon device? 


EXAMPLES OF TYPES OF ERROR INFORMATION CAPTURED BY NPDA 




Power on local/remote modem 


1. 

2. Incorrect NCPGEN, correct it (reply to incorrect) 
5. Run link test 

4. Run line trace 

ETC. 


BfllELES OF ACTIO NS THAT NPDA MAY SUGGEST 










BTAM 


1. PART OF APPLICATION 

2. AS MANY BTAMs AS APPLICATION 

3. SEPERATE NETWORK FOR 
EACH APPLICATION 


ONLINE 1 


BTAM 


NON TP JOBS 



NON TP JOBS 

ONLINE. 1 

V . 

T 

A 

M 

1 

ONLINE 2 


VTAM 


1. VTAM RUNS AS SEPERATE 
JOB 

2. ONLY ONE VTAM IS NECESSARY 

3. APPLICATIONS SHARE NETWORK 

4. AVAILABLE BOTH WITH OS AND 
DOS 


r NON tP JOBS 

ONLINE 1 

T 

1 

C 

ONLINE 2 

l 

M 



TCAM 


1. TCAM RUNS AS A SEPERATE 
JOB 

2. ONLY ONE TCAM IS NECESSARY 

3. APPLICATIONS SHARE NETWORK 

4. AVAILABLE WITH OS ONLY 

5. APPLICATIONS VIEW NETWORK 
AS SEQUENTIAL FILE AND USE 
TCAM Qs 









PROTOCOLS 


>U§-TII^ ii 0 ^ c iii^ 
HOST 


BSC 

SS 

IN HOST 

SIMPLE 

BSC 


EXTENSIVE 

SS 

, 

IN HOST (EP) 

IN 3705 (NCP) 


SDLC 

- MORE 

EXTENSIVE 



IN NCP 

EXTENSIVE 

SDLC 

IBM 3270 

-MORE 

EXTENSIVE 



iRE(mRY 


NONE 


QS AND NETWORK 


NETWORK 


FUNCTIONAL COMPARISON - 1 






















RESOURCE 

SHARING 

FUNC 

OISTR. 

OPERATOR 

COMMANDS 

TUNING 

PERFORMANCE 

SYSGEN 

INSTLL. 

STORAGE 

BTAM 

MINIMAL 

NONE 

NONE 

EASY 

VERY GOOD 

VERY SIMPLE 

>50 K 

TCAM 

EXTENSIVE 

YES 

YES 

VERY 

COMPLEX 

MOST 

OVERHEAD 

MOST COMPLEX 

3/4 MEG 

VTAM 

EXTENSIVE 

VE5 

YES 

COMPLEX 

HIGH 

OVERHEAD 

VERY COMPLEX 

1/2 MEG 


FUNCTIONAL COMPARISON - 2 




VTAM 


VTAM 


BTAM or TCAM 



BSC/SS 


BTAM or TCAM 
- --TCBM j 


1 


V. 



BTAM or TCAM 



prp 

» U.I 

''X 1 — ocr /cc 

— a L)OW *30 

„ 3;-BSC/SS 

NCP 

(NTO) 

- 3—SDLC(SNA). SELECTED 

KLS 

BSC/SS 


IBM DEVICE SUPPORT SUMMARY 







LARGE NUMBER OF PERMUTATIONS/COMBINATIONS 

ALL MAJOR TERMINAL PRODUCTS SUPPORTED IN ALL 

ENVIRONMENTS 

THERE IS LIFE BEYOND IBM, "THINK" ALTERNATIVES: 

- COMTEN 
CCI 

OTHERS 




DEVICE SUPPORT: SUMMARY AND CONCLUSIONS 



SNA AN D T ELEPROCESSING ACCESS METHODS 


TOPICS DICUSSED 


PRE-SNA! 

BTAM 

EP 

TP MONITORS 
CICS 
IMS 


Z3.T-0 i 


SNA: 

ACF/VTAM 

Tt6F/TGA » 

ACF/NCP 

NTO 

MSNF 

NCCF 

NPDA 


LARGE AMOUNT OF INFORMATION, FAIRLY COMPLEX 

A GOOD STARTING POINT FOR MORE IN DEPTH STUDY 
OF TOPICS INVOLVED 


'SAFE JOURNEY HOME'. 





